Talk:Code of Conduct: Difference between revisions

From coreboot
Jump to navigation Jump to search
m (Include a TOC)
 
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Draft version, adapted from openbios' "Project Statement" ==
Our Code of Conduct is a pretty new work, and might benefit from some refinement in a couple of places. Let's discuss things here, so we can adopt sensible changes.
Dear coreboot project members and other interested parties,


For the ease of development and for information on what can be expected from this project we want to set down the following ground rules in order to achieve a high quality implementation of our project objectives.
Proposed rules for changes (that are open for discussion as well): Changes will be accepted when the "pros" seriously outweigh the "cons" (ideally there are none of the latter) and when the arbitration team agrees (since they will bear the load).


# The objective of this project is to develop a free, open source firmware implementation with broad hardware support.
__TOC__
# We cannot allow _any_ discussion or use of _any_ copyrighted, patented, or otherwise protected Firmware or BIOS implementations without an OSI approved license in this project or on the mailing list associated with this project. All members of this project and/or the according mailing lists agree to not disclose or use any copyrighted, patented, or otherwise protected information, ideas or concepts.
# We do not intend to bind ourself to any interface, be it something IBMBIOS alike, EFI or anything else. All of them are welcome as payloads, as long as they don't restrict our freedom to develop firmware.
# In order to assure truly universal implementation and/or optimize the functionality and performance it is our expressed wish to work in conjunction with other open source projects.
# Cooperation with hardware vendors is necessary to implement this project on an architecture-independent basis. In certain cases this may include signing non-disclosure agreements with the aforementioned hardware vendors in an attempt to acquire hardware specific information or support that may not otherwise be available although the results of such cooperation must be freely redistributable.
# Cooperation with any university, research project, or organization is desired except in such cases where the resulting information is restricted in use or redistributability.


If, for whatever reasons, any of the above statements are unacceptable or seem to be incorrect or unclear in _any_ way please do not hesitate to discuss this matter on the mailing list, we are open for suggestions. This is simply an attempt to assure the legal status of this project, protecting those involved from legal prosecution as well as to state the general objectives of the project.


coreboot development team.
== Singling out "Harassment" ==
Carl-Daniel is [http://www.coreboot.org/pipermail/coreboot/2015-January/079116.html unhappy] with the list after "Harassment includes:", because it (as Patrick understands it) singles out that behavior, minimizing the others (that are just as horrible).
 
'''Proposal''': Remove the paragraph "Harassment includes:" completely.
 
'''Pros''': Less emphasis on "harassment", hopefully making it (more) clear that all of the unacceptable behaviors are horrible.
 
'''Cons''': ???
 
I (Carl-Daniel) think that Stefan's version of Patrick's proposal to instead label that list "Examples of behaviors we do not accept in our community" is a good idea and will not pursue the removal further.
 
== Rephrase the 'check your motives' part ==
 
'''Proposal''': Rephrase "Check your motives: Using this code of conduct aggressively against other people in the community might also be harassment. Behave." to be [http://www.coreboot.org/pipermail/coreboot/2015-January/079134.html friendlier]
 
'''Pros''': The proposed version is a real improvement.
 
'''Cons''': ???
 
Done.
 
== Some words about assessing code quality ==
 
'''Proposal''': Add to the list in the chat etiquette something like: 'Code that you are changing wasn't perfect (or you wouldn't change it). However, try to avoid assuming that it was written by monkeys, or that it must have always been broken. It's likely that it used to work and it's likely that your new work is necessary and important because circumstances changed where the code didn't.'
 
'''Pros''': Remind people that there's a coder behind the code. Assuming bad intent or stupidity (and doing so publicly) is as much a statement about the code as about the coder.
 
'''Cons''': Is that micromanaging things?

Latest revision as of 23:31, 7 February 2015

Our Code of Conduct is a pretty new work, and might benefit from some refinement in a couple of places. Let's discuss things here, so we can adopt sensible changes.

Proposed rules for changes (that are open for discussion as well): Changes will be accepted when the "pros" seriously outweigh the "cons" (ideally there are none of the latter) and when the arbitration team agrees (since they will bear the load).


Singling out "Harassment"

Carl-Daniel is unhappy with the list after "Harassment includes:", because it (as Patrick understands it) singles out that behavior, minimizing the others (that are just as horrible).

Proposal: Remove the paragraph "Harassment includes:" completely.

Pros: Less emphasis on "harassment", hopefully making it (more) clear that all of the unacceptable behaviors are horrible.

Cons: ???

I (Carl-Daniel) think that Stefan's version of Patrick's proposal to instead label that list "Examples of behaviors we do not accept in our community" is a good idea and will not pursue the removal further.

Rephrase the 'check your motives' part

Proposal: Rephrase "Check your motives: Using this code of conduct aggressively against other people in the community might also be harassment. Behave." to be friendlier

Pros: The proposed version is a real improvement.

Cons: ???

Done.

Some words about assessing code quality

Proposal: Add to the list in the chat etiquette something like: 'Code that you are changing wasn't perfect (or you wouldn't change it). However, try to avoid assuming that it was written by monkeys, or that it must have always been broken. It's likely that it used to work and it's likely that your new work is necessary and important because circumstances changed where the code didn't.'

Pros: Remind people that there's a coder behind the code. Assuming bad intent or stupidity (and doing so publicly) is as much a statement about the code as about the coder.

Cons: Is that micromanaging things?