Richard Freeman <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 -- [EMAIL PROTECTED] mailing list
