On Tue, Aug 13, 2013 at 08:20:28PM +0200, Wouter Verhelst wrote: > slap others with the code of conduct. Enrico also raised a number of > other points, but I'm afraid I'll have to say that I forgot much of > it; I'll have to ask him to raise them again on the list. Sure. I thought discussing this CoC was difficult because I feel that its design goal hasn't been defined very clearly, and so everyone tries to stretch it in different directions depending on their personal feelings and priorities. I think that a work like this needs to start with an analysis of who the "users" of such a document are, what are their goals, how the document could help them. Once it is clear what problem we're trying to solve, whom we're talking to and what is in it for them, then it gets remarkably easier to write good stuff. If we are trying to create a document that people can be pointed at when they're having a bad day, then we should keep in mind that the document will be read by someone who, well, is having a bad day. It should treat the reader with the utmost respect, be extremely coincise, and offer useful reminders. "Whoops, I screwed up, what can I do to limit the damage?" -- I'd be curious to see what a document like that would look like. If we are trying to document the bits of the status quo that work, so that they are proposed as a baseline standard, then we're addressing newcomers and people who have just been on the wrong side of someone's bad day. People could use it to realise when someone is deviating from some standard, and decide whether the deviation is creative or destructive. I don't think that a document could be written that fits both goals, so I would pick one goal at a time and focus on creating something that does the job for that, and that thing only. If I were to try and reverse-engineer the users and goals of the CoC that was proposed, I'd get the feeling of something written by old-timers to express their frustration about what it is that makes discussion difficult. I think that's also a worthwhile document to write, but it shouldn't be called a CoC. It would rather be the description of a problem that we're trying to solve. If it were a piece of software, I'd say that we've jumped straight into writing code, without spending enough time understanding the requirements, and agreeing on them. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>
Attachment:
signature.asc
Description: Digital signature