On Wed, Mar 05, 2014 at 06:05:45PM +0000, Neil McGovern wrote: > On Wed, Mar 05, 2014 at 05:53:48PM +0000, Neil McGovern wrote: > > Seconded, but I'd also like a couple of amendments which I'll add in > > another mail. > > > > And here's those amendments. > > Amendment A - move mailing list CoC text to "further reading" > Justification: I think that it's better to keep the CoC as a general > purpose document, rather than have it specific to each medium. The > information at http://www.debian.org/MailingLists/#codeofconduct is > still useful as it stands. > > I'm hopeful Wouter will accept this one, as I don't think it > substantially changes the CoC. > > --------- > participants to its mailinglists, IRC channels, and other modes of > communication within the project. > > -2. The initial text of this code of conduct replaces the "mailinglist > - code of conduct" at http://www.debian.org/MailingLists/#codeofconduct > - > -3. Updates to this code of conduct should be made by the DPL or the > +2. Updates to this code of conduct should be made by the DPL or the > DPL's delegates after consultation with the project, or by the Debian > Developers as a whole through the general resolution procedure. > > -4. The initial text of the code of conduct follows, in markdown format. > +3. The initial text of the code of conduct follows, in markdown format. > > # Debian Code of Conduct > > [snip] > - Debian has a [diversity statement](http://www.debian.org/intro/diversity) > - The [Debian Community Guidelines](http://people.debian.org/~enrico/dcg/) > by Enrico Zini contain some advice on how to communicate effectively. > +- The [Mailing list code of > + conduct](http://www.debian.org/MailingLists/#codeofconduct) is useful for > + advice specific to Debian mailing lists > --------- After some consideration, I accept this amendment. The original goal of my proposed CoC was to replace the original the mailinglist code of conduct, as I considered it of somewhat limited use. To keep it and point to it would therefore somewhat defeat my original purpose. However, it is now clear that listmasters disagree; and as there are reasonable arguments for some of the things in the mailinglist coc, even though I think they should probably be in a different kind of document, I accept that my proposed CoC is not a replacement. So it does make sense to keep it, even if that's not what I had planned for. > Amendment B - Updates to the CoC should be via developers as a whole > Justification - I believe that this document should have the strength of > being a whole project statement. Being able to be updated by a single > person doesn't feel comfortable with me. > > I'm less convinced Wouter will accept this, but I think it should be on > the ballot! > > --------- > 2. The initial text of this code of conduct replaces the "mailinglist > code of conduct" at http://www.debian.org/MailingLists/#codeofconduct > > -3. Updates to this code of conduct should be made by the DPL or the > - DPL's delegates after consultation with the project, or by the Debian > - Developers as a whole through the general resolution procedure. > - > -4. The initial text of the code of conduct follows, in markdown format. > +3. The initial text of the code of conduct follows, in markdown format. > > # Debian Code of Conduct > --------- The reason for that clause in my proposal was some discussion (not sure anymore whether it was during the BoF or on -project) where most people seemed to be in favour of allowing the DPL to make changes, rather than having to go through what might be a lengthy and tiresome GR procedure; but my original idea was to use a GR, too. In other words, I might not be as opposed to this as you think ;-) Having said that, I do think the "further reading" section should *not* require a GR to be updated. Useful documents get written all the time, and adding such a link to the document should not be controversial, no matter what. So rather than accepting this amendment, I propose that we modify paragraph 3 read as follows, instead: ------- 3. Updates to this code of conduct should follow the normal GR procedure. However, the DPL or the DPL's delegates can add or remove links to other documents in the "Further reading" section after consultation with the project and without requiring a GR. ------- The idea here is that a DPL can add a link to something considered useful, while "normal" DD's can still add such a link through a GR if the DPL is opposed. How's that sound? -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/
Attachment:
signature.asc
Description: Digital signature