Language Discussion Summaries
Miko O'Sullivan
Members of the Perl6 Language list produce summaries discussions of
proposed features of the Perl6 language. These summaries will improve the
signal to noise ratio for Larry and his lieutenants as they try to keep up
with feelings in the list. See http://www.idocs.com/perl6/ for the first
example of a summary.
DETAILS
With Damian taking a break from the list, I've become concerned that ideas
generated in this list will become buried in the volume of messages. If
Larry, Damian, and other members of the core team have to read through
every bottomless thread just to find out the ideas and opinions of the
list members, they may never be able to keep up.
Therefore, I propose that members of the language list provide summaries
of the discussions in the group. Each summary describes a proposed idea
feature of the language, then summarizes the list's feelings on the idea.
Different opinions will be presented. The summaries will also attempt to
provide a feeling for the weight of opinion, e.g., "most people felt this
way", "some people felt differently", etc. The summaries will also link to
the original threads so that readers can peruse the raw data.
Although these summaries will be necessarily subjective, the authors will
attempt to be journalistically objective. The authors will be clearly
identified. If the authors participated in the thread, that fact will
also be identified. Finally, anybody on the list who chooses may add a
note that they concur with the summary (sorta like in science journals
where "authors" are simply people who agree). Dissenting opinions (i.e.
people who think the summary is innaccurate) might also be presented, but
I'd rather just incorporate those opinions into the summary and reach a
consensus that the summary correctly summarizes the thread.
See http://www.idocs.com/perl6/ for the home page for the summaries and
one example summary.
-miko
Miko O'Sullivan
Programmer Analyst
Rescue Mission of Roanoke
Murat Ünalan
Murat
Allison Randal
>
> Therefore, I propose that members of the language list provide summaries
> of the discussions in the group. Each summary describes a proposed idea
> feature of the language, then summarizes the list's feelings on the idea.
> Different opinions will be presented. The summaries will also attempt to
> provide a feeling for the weight of opinion, e.g., "most people felt this
> way", "some people felt differently", etc. The summaries will also link to
> the original threads so that readers can peruse the raw data.
Go for it. It might not catch on, but it's worth a try. Keep in mind
that Piers' summaries already cover a good part of this, but if you do
it right you might make his job easier. :)
In general, it should probably be the responsibility of the original
poster to summarize the thread.
Allison
Piers Cawley
> Miko O'Sullivan wrote:
>>
>> Therefore, I propose that members of the language list provide summaries
>> of the discussions in the group. Each summary describes a proposed idea
>> feature of the language, then summarizes the list's feelings on the idea.
>> Different opinions will be presented. The summaries will also attempt to
>> provide a feeling for the weight of opinion, e.g., "most people felt this
>> way", "some people felt differently", etc. The summaries will also link to
>> the original threads so that readers can peruse the raw data.
>
> Go for it. It might not catch on, but it's worth a try. Keep in mind
> that Piers' summaries already cover a good part of this, but if you do
> it right you might make his job easier. :)
Hell yes. Actually my summaries run on a different 'clock' to thread
summaries; I'd expect thread summaries to get written after a given
thread has pretty much died down (or at least started repeating itself
too often) whereas my summaries get produced to a weekly timetable,
which isn't necessarily the same as the threads (see the last few
summaries where the same thread has appeared repeatedly)
--
Piers
Murat Ünalan
> people felt this way", "some people felt differently", etc.
One should trace back who was of what opinion. So my suggestion would be
Discussion: "Foo feature"
"Want it": Person A, Person B, Person C, Person D
"Reject it: Person E, Person F, Person G, Person H
"Neutral": Person I
So posters should also may try to give a "clean" statement on there
final posts
how they feal about the feature.
Like
I think that, but this is....
Vote: "reject this feature".
Murat
Luke Palmer
> Date: Tue, 4 Feb 2003 10:21:11 +0100
>
> > to provide a feeling for the weight of opinion, e.g., "most
> > people felt this way", "some people felt differently", etc.
>
> One should trace back who was of what opinion. So my suggestion would be
>
> Discussion: "Foo feature"
> "Want it": Person A, Person B, Person C, Person D
> "Reject it: Person E, Person F, Person G, Person H
> "Neutral": Person I
I don't think we would really need a "Neutral" list...
> So posters should also may try to give a "clean" statement on there
> final posts
> how they feal about the feature.
So, would this precise list really help the design team in making
decisions. As I see it, they don't care how many of us like a
particular feature; on the contrary, they're using us as idea
machines. If one person comes up with an idea they like, and most
people hate it, they might still use it.
I think the original "general consensus" is fine, and a more specific
list would only bog down the summaries.
> Like
>
> I think that, but this is....
> Vote: "reject this feature".
Vote: "reject this idea" :)
Luke
Miko O'Sullivan
push forward with a few. I invite everyone here to join in.
The idea is *not* that Miko writes summaries of every thread. The idea is
that the proponent of an idea, or someone very interested in an idea,
writes a summary as a clean final presentation of the idea and its
reception.
Submitting a summary of your pet proposed feature is a good way to put the
idea in front of the decision makers. You can show off your idea without
the clutter of endless detailed commentary. That being said, you still
need to present a balanced summary of the all opinions, including those
you disagree with.
The summaries will be located at http://www.idocs.com/perl6/
Here's how to submit a summary. Use the template at
http://www.idocs.com/perl6/template.html . The HTML is set to use the
stylesheets on my server, so you can edit the summary on your own machine
and submit it once it's clean and ready. Email the summary to me at
mi...@idocs.com. The summary should be written after discussion of the
idea has winded down. I won't announce in the list the appearance of
individual summaries, but I will occasionally post a list of new
summaries.
I'll be starting with three of my own favorites: vrep
(http://archive.develooper.com/perl6-l...@perl.org/msg09684.html), the
monolithic "Loop controls" thread
(http://archive.develooper.com/perl6-l...@perl.org/msg09684.html), and
named params in subroutines
(http://archive.develooper.com/perl6-l...@perl.org/msg09551.html).
-Miko
Buddha Buck
> The idea of discussion summaries has been well received, so I'm going to
> push forward with a few. I invite everyone here to join in.
>
> The idea is *not* that Miko writes summaries of every thread. The idea is
> that the proponent of an idea, or someone very interested in an idea,
> writes a summary as a clean final presentation of the idea and its
> reception.
Hmmm... I'm looking at this and I'm wondering....
You suggest doing it in HTML. Wouldn't it make more sense to do it in
POD, the standard documentation language for Perl?
And how do these differ in concept to the RFC process Perl 6 has already
gone through? Wouldn't it make sense, assuming that clean, final
presentations of proposed ideas or features in Perl are useful, to
re-open the RFC process?
Miko O'Sullivan
> You suggest doing it in HTML. Wouldn't it make more sense to do it in
> POD, the standard documentation language for Perl?
For now, since it's a web site, let's stick to HTML. If somebody just way
prefers POD, contact me off list and we'll figure out the best way to
proceed.
> And how do these differ in concept to the RFC process Perl 6 has already
> gone through? Wouldn't it make sense, assuming that clean, final
> presentations of proposed ideas or features in Perl are useful, to
> re-open the RFC process?
RFC's are proposals before the comments. The summaries are, well,
summaries of the comments. My main concern is that Larry, Damian, et al,
are likely to have a hard time reading through all the comments in the
language list (Damian isn't even in the list right now), so the summaries
are a way of letting them cut to the chase on the discussion of each idea.
-miko
Buddha Buck
>>And how do these differ in concept to the RFC process Perl 6 has already
>>gone through? Wouldn't it make sense, assuming that clean, final
>>presentations of proposed ideas or features in Perl are useful, to
>>re-open the RFC process?
>
>
> RFC's are proposals before the comments. The summaries are, well,
> summaries of the comments. My main concern is that Larry, Damian, et al,
> are likely to have a hard time reading through all the comments in the
> language list (Damian isn't even in the list right now), so the summaries
> are a way of letting them cut to the chase on the discussion of each idea.
You are aware the that RFCs went through a revision process, and the
"finalized" RFCs that the Design Team are looking at are supposed to
include the final form of the idea after discussion, and a summary of
what was thought of it? Many of the RFCs weren't written until after
the idea had been discussed.
Miko O'Sullivan
> You are aware the that RFCs went through a revision process, and the
> "finalized" RFCs that the Design Team are looking at are supposed to
> include the final form of the idea after discussion, and a summary of
> what was thought of it? Many of the RFCs weren't written until after
> the idea had been discussed.
Sure, I'm aware of that. However, the language list goes on (and
sometimes, on and on and on). If those discussions are to be useful,
somebody needs to summarize them.
Jonathan Scott Duff
Buddha Buck's comments aside, I think thread-summaries would be a
useful thing. But probably only if we continue to have these long
seemingly endless threads. Better might be someone who's there to
shout "LET'S WRAP IT UP PEOPLE!" every now and then. And maybe that
someone is Miko :-)
-Scott
--
Jonathan Scott Duff
du...@cbi.tamucc.edu
gre...@focusresearch.com
(couldn't resist)
-- Gregor
Jonathan Scott Duff <du...@cbi.tamucc.edu>
02/04/2003 11:38 AM
Please respond to duff
To: Buddha Buck <bmb...@14850.com>
cc: "Miko O'Sullivan" <mi...@idocs.com>, perl6-l...@perl.org
Subject: Re: Language Discussion Summaries
Smylers
> The idea of discussion summaries has been well received, ...
I read this thread over the past couple of days. It's only today that,
having thought about it, an objection occurred to me. I've no problem
with people summarizing threads, but with this bit:
> The summaries will be located at http://www.idocs.com/perl6/
Why?
I read the Perl 6 language list with a news-reader, which conveniently
shows new articles when it's run. People subscribed to read this by
e-mail get similar service. I don't want to have to remember to check a
webpage on a regular basis just to see if anything new has cropped up
there.
Couldn't thread summaries just be sent to this list? Piers would almost
certainly link to them in his weekly summaries -- he has done previously
when people, most notably MikeL, have posted ad hoc summaries of
particular topics.
So Damian, and anybody else who doesn't read every message but still
follows Piers's excellent updates, would still have thread summaries
drawn to his attention and be able to read them.
Smylers
Piers Cawley
> Miko O'Sullivan wrote:
>
>> The idea of discussion summaries has been well received, ...
>
> I read this thread over the past couple of days. It's only today that,
> having thought about it, an objection occurred to me. I've no problem
> with people summarizing threads, but with this bit:
>
>> The summaries will be located at http://www.idocs.com/perl6/
>
> Why?
>
> I read the Perl 6 language list with a news-reader, which conveniently
> shows new articles when it's run. People subscribed to read this by
> e-mail get similar service. I don't want to have to remember to check a
> webpage on a regular basis just to see if anything new has cropped up
> there.
>
> Couldn't thread summaries just be sent to this list? Piers would almost
> certainly link to them in his weekly summaries -- he has done previously
> when people, most notably MikeL, have posted ad hoc summaries of
> particular topics.
That's definitely a good idea. With the added advantage that, if a
reader wants, the whole thread is immediately accessible for further
investigation.
--
Piers