-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. As somebody else pointed out in a reply to one of my emails (which I totally agree with) - flames (aka poisonous content) aren't welcome anywhere. 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. 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. As an example I tended to disagree with the point you were raising, but I'd hope we could agree that I'm attempting to be constructive in my reply and that I'm trying to focus on what is good for Gentoo and not my personal agenda. If I had just replied with a one-liner of some sort it would be less constructive. Even so, this is inherently a political discussion and those devs on this list who would prefer to just work on their herds and not worry about moderation/ CoC/ religious positions on package managers/ etc. would probably prefer that it took place on -project - not because the debate isn't important, but simply because it isn't what they're interested in reading about. I've participated in moderated lists which weren't perceived as one-sided or as creating a division between valued and unvalued posters. Often a majority of posts are moderated, and the only thing the moderator does is determine whether the post adds value to the conversation. One-liners get rejected regardless of who sends them - and genuine arguments get accepted regardless of where they line up against the party view. Such lists benefit from a diversity of opinions and don't get as bogged-down in groupthink. They also tend to be more inviting to outsiders. Flames really shouldn't be welcome on any list. I know there are posters on this list that drive most of the devs crazy - and it is easy for me to just say not to fight fire with fire. I know that when devs do reply with one-liners nobody thinks less of them for it as a result (I am not certain I'd act any differently if I were in their shoes). However, that isn't good for the project - it tends to create a strong core team that circles the wagons against outside dissent - which is good when the dissent is just an annoying party of raiders, but it can lead to less flexibility and an unwillingness to tolerate dissent of any kind. I'm sure the XFree86 team is still a tight-knit group that is happy with the licensing decision they made some time ago, even though as a result they're almost entirely irrelevant to the FOSS world now. I think the -dev / -project division is good, and I think it will make a lot of devs happy - if for no other reason than they don't need to read discussions like this one... :) However, if anybody thinks that it will succeed in getting rid of certain unpopular voices on this list I think they will be disappointed - they will go where the discussion is. At best the division will let people choose what discussion they participate in - not who participates in those discussions. Maybe we can just be optimistic that at some point we'll learn how to disagree maturely... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGpBM3G4/rWKZmVWkRAglhAJ9AYoXcvhIYd5hMYQBElNm4CMfgWACgqEoD n8pSc8R9O1cpAezKxAEnaaY= =XqMN -----END PGP SIGNATURE-----
smime.p7s
Description: S/MIME Cryptographic Signature
