|Dave Neary||Dec 1, 2006 6:02 am|
|Murray Cumming||Dec 1, 2006 7:05 am|
|Adrian Custer||Dec 1, 2006 7:36 am|
|Dave Neary||Dec 1, 2006 9:31 am|
|Murray Cumming||Dec 1, 2006 9:44 am|
|Danilo Šegan||Dec 1, 2006 10:43 am|
|Murray Cumming||Dec 1, 2006 11:03 am|
|Anne Østergaard||Dec 1, 2006 11:11 am|
|Glynn Foster||Dec 1, 2006 12:24 pm|
|Murray Cumming||Dec 1, 2006 12:34 pm|
|Mariano Suárez-Alvarez||Dec 1, 2006 7:02 pm|
|Alan Horkan||Dec 1, 2006 9:06 pm|
|Dave Neary||Dec 2, 2006 1:24 am|
|Alan Horkan||Dec 2, 2006 2:02 am|
|Johannes Schmid||Dec 2, 2006 5:21 am|
|Quim Gil||Dec 2, 2006 5:55 am|
|Alan Horkan||Dec 2, 2006 6:29 am|
|Danilo Šegan||Dec 3, 2006 1:35 pm|
|Adam Schreiber||Dec 3, 2006 1:47 pm|
|Philip Van Hoof||Dec 4, 2006 8:50 am|
|Olav Vitters||Dec 4, 2006 9:53 am|
|Philip Van Hoof||Dec 4, 2006 10:27 am|
|Olav Vitters||Dec 4, 2006 10:49 am|
|Murray Cumming||Dec 4, 2006 11:44 am|
|Philip Van Hoof||Dec 4, 2006 12:13 pm|
|Andrew Sobala||Dec 4, 2006 12:49 pm|
|Elijah Newren||Dec 4, 2006 2:53 pm|
|Jeff Waugh||Dec 4, 2006 3:02 pm|
|Telsa Gwynne||Dec 8, 2006 1:26 pm|
|Dave Neary||Dec 8, 2006 2:42 pm|
|Quim Gil||Dec 8, 2006 3:39 pm|
|Alan Horkan||Dec 10, 2006 7:02 pm|
|Jeff Waugh||Dec 10, 2006 7:42 pm|
|Quim Gil||Dec 12, 2006 3:58 pm|
|Quim Gil||Dec 12, 2006 4:07 pm|
|Murray Cumming||Dec 14, 2006 2:59 am|
|Murray Cumming||Jan 16, 2007 6:40 am|
|Subject:||Re: Code of conduct (bis)|
|From:||Anne Østergaard (an...@oestergaard.nu)|
|Date:||Dec 1, 2006 11:11:28 am|
fre, 01 12 2006 kl. 16:06 +0100, skrev Murray Cumming:
On Fri, 2006-12-01 at 15:02 +0100, Dave Neary wrote:
A while back, Murray asked the board to pronounce itself on the code of conduct.
We have had several debates on the issue, both on the mailing list and on conference calls, and Murray asked me to relay the conclusions to the membership.
The feeling of the board (a majority opinion, rather than unanimous) is that the code of conduct would be more hurt than helped by being pushed by us. Its adoption really needs to be bottom-up.
Thanks for being the messenger. I am deeply disappointed by this. I think it's a failure of leadership and a failure to stand up for our most basic common values. From an otherwise sensible board.
This was really the only way that this could be done. It will be logistically almost impossible for me to individually persuade every single mailing list, project maintainer, and sysadmin to endose this explicitly. But "GNOME rejects Code of Conduct" is such an awful signal that I'll try to do that anyway.
Or do the new board candidates see this more clearly? http://live.gnome.org/CodeOfConduct
Hi Murray and everyone
I am in favor of a code of conduct.
Here is my go of a text:
Ethical Guidelines for GNOME. GNOME Code of Conduct - 1.0. This is the current version of this code of conduct.
= GNOME Code of Conduct =
This Code of Conduct covers your behavior as a member of the GNOME Community, in any forum, mailing list, Wiki, web site, IRC channel, install-fest, public meeting or private correspondence.
'''Be considerate.''' Your work will be used by other people, and you in turn will depend on the work of others. Any decision you take will affect users and colleagues, and we expect you to take those consequences into account when making decisions. For example, when we are in a feature freeze, please don't upload dramatically new versions of critical system software, as other people will be testing the frozen system and will not be expecting big changes.
'''Be respectful.''' The GNOME community and its members treat one another with respect. Everyone can make a valuable contribution to GNOME. We may not always agree, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It's important to remember that a community where people feel uncomfortable or threatened is not a productive one. We expect members of the GNOME community to be respectful when dealing with other contributors as well as with people outside the GNOME project and with users of GNOME.
'''Be collaborative.''' GNOME and Free Software are about collaboration and working together. Collaboration reduces redundancy of work done in the Free Software world, and improves the quality of the software produced. You should aim to collaborate with other GNOME maintainers, as well as with the upstream community that is interested in the work you do. Your work should be done transparently and patches from GNOME should be given back to the community when they are made, not just when the distribution releases. If you wish to work on new code for existing upstream projects, at least keep those projects informed of your ideas and progress. It may not be possible to get consensus from upstream or even from your colleagues about the correct implementation of an idea, so don't feel obliged to have that agreement before you begin, but at least keep the outside world informed of your work, and publish your work in a way that allows outsiders to test, discuss and contribute to your efforts.
'''When you disagree,''' consult others. Disagreements, both political and technical, happen all the time and the GNOME community is no exception. The important goal is not to avoid disagreements or differing views but to resolve them constructively. You should turn to the community and to the community process to seek advice and to resolve disagreements.
'''When you are unsure,''' ask for help. Nobody knows everything, and nobody is expected to be perfect in the GNOME community. Asking questions avoids many problems down the road, and so questions are encouraged. Those who are asked should be responsive and helpful. However, when asking a question, care must be taken to do so in an appropriate forum. Off-topic questions, such as requests for help on a development mailing list, detract from productive discussion.
'''Step down considerately.''' Developers on every project come and go and GNOME is no different. When you leave or disengage from the project, in whole or in part, we ask that you do so in a way that minimizes disruption to the project. This means you should tell people you are leaving and take the proper steps to ensure that others can pick up where you leave off.