[gentoo-dev] Re: New lists and their usage

[Duncan]

Richard Freeman <rich@××××××××××××××.net> posted
46A4133A.4030007@××××××××××××××.net, excerpted below, on  Sun, 22 Jul 2007
22:32:26 -0400:

> Jan Kundrát wrote:
>> Ryan Hill wrote:
>>> zombieswift/new devs		-project
>>> council/trustee nominations		-project
>>
>> Then it's worth cross-posting -core or -dev-announce or similar. I
>> thought that goal of -project was to keep devs away from poisonous
>> content without impairing their Gentoo-awareness.
>>
> I thought the goal was more to separate technical and non-technical
> content - as most of the heavy-reply emails on -dev were non-technical
> in nature.  The politics/etc could go on -project.

[snip]
 
> If anything of any importance at all gets discussed on -dev, then all
> the non-technical stuff will end up on -dev as well and nothing will be
> accomplished by having the new list.  Developers who are interested in
> participating in politics (devrel, CoC debates, user-relation
> discussions, etc) should subscribe to -project.

The idea is this.  For non-tech posts, X-post the /first/ post, the 
announcement of the idea (for new devs, nominations, etc, to both dev and 
dev-announce), so those only paying attention to dev know about it.  Set 
the followup to project (not dev).  Those who wish to discuss it, the 
discussion goes to project.

If/when a decision is made, the announcement of the decision is made to 
dev-announce and dev, again xposted and fup2 set to project.

For most non-technical stuff then, dev will normally get two posts, the 
initial idea announcement, and the decision announcement if one is made.  
Dev-announce will get one, the final decision.

Foundation and council nominations are a bit strange in this regard, 
since generally, the thread starter is an announcement, but arguably so 
are the nominations and accept/reject notices.  This one's tough, but I'd 
call it an exception.  The best idea I can come up with here is initial 
nominations open announcement to dev-announce, xposted to dev, with fup2 
set to dev (not project, the single non-tech exception).  That will keep 
dev-announce noise really low, while allowing the nominations and accept/
reject on dev, one step above where they'd normally be because they are 
announcements, but not on announce, to keep the noise there lower.  In 
keeping with this exception, the original nominations open announcement 
should say those and acceptance/rejection notices are welcome on dev, but 
that any discussion thereof should be on project only.

Then an elections official appointed to the job should produce a summary 
a few days before nominations close with nominations to date, and again 
as nominations close and elections begin.  This summary should go to dev-
announce, xposted and fup2 set to dev for more nominations for the pre-
close announcement, and to project for the nominations close, elections 
begin, announcement.

So for nominations, there'd be three posts to dev announce instead of 
two, the opening announcement, the pre-close summary, and the final 
summary, marking the opening of elections.

> One thing I want to caution is a potentially-dangerous mindset that a
> flame is any post that one personally disagrees with - or which a
> majority of developers disagree with.  Flames are more about attitude
> and intent - not so much about viewpoint. [snip]

++

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@g.o mailing list