Differences between revisions 3 and 4
Revision 3 as of 2007-06-02 12:39:15
Size: 7055
Editor: cpe-66-67-122-162
Comment: Grammar changes to community guidelines. Other changes to project guidelines.
Revision 4 as of 2007-06-02 12:45:55
Size: 7147
Editor: cpe-66-67-122-162
Comment: Add liks to CLA and Greg's classic author tag post.
Deletions are marked like this. Additions are marked like this.
Line 39: Line 39:
|| 6 || Project source code and documentation must be donated to the ASF under a Contributor's License Agreement. Donated source code and documentation must carry the ASF copyright and be placed under the Apache License. Code and documentation donated to the ASF must be maintained on ASF hardware. Obtaining a non-exclusive ASF copyright on all material in the ASF repository is encouraged. || || 6 || Project source code and documentation must be donated to the ASF under a [http://apache.org/licenses/index.html#clas Contributor's License Agreement]. Donated source code and documentation must carry the ASF copyright and be placed under the Apache License. Code and documentation donated to the ASF must be maintained on ASF hardware. Obtaining a non-exclusive ASF copyright on all material in the ASF repository is encouraged. ||
Line 44: Line 44:
|| B || Author tags in source code are discouraged but permitted. || || B || [http://tinyurl.com/mw7t6 Author tags] in source code are discouraged but permitted if a PMC so prefers. ||

Some ASF Members have indicated a wish to draft a [http://en.wikipedia.org/wiki/Code_of_conduct code of conduct]. This area is intended to help volunteers collaborate on an ASF Code of Conduct and related documents. Whether or not the foundation should have such a code has not been determined.

THESE ARE DRAFT DOCUMENTS FOR DISCUSSION PURPOSES ONLY.

Community Guidelines

THIS IS A DRAFT DOCUMENT FOR DISCUSSION PURPOSES ONLY.

The Apache Software Foundation creates and maintains open source products for the public benefit utilizing an open, collaborative approach to software development. Our products are developed by a diverse community of volunteers, most of whom use our software products in the course of their own daily lives. Our development discussions are held over public mailing lists. Everyone is invited to join the discussion so long as the usual courtesies of [http://en.wikipedia.org/wiki/Netiquette email netiquette] are observed.

In addition, we wish to emphasize that while the foundation embraces the spirit of civil disagreement, we do not sanction personal attacks or the posting of off-topic content.

  • The foundation embraces the spirit of civil disagreement. As an organization devoted to creating software of the highest quality, we agree to agree and to disagree -- as strongly as need be -- without crossing the boundary into personal attacks or the posting of off-topic content.
  • The foundation defines personal attacks as "criticizing the coder rather than the code". It is acceptable to criticize an idea, it is not acceptable to criticize the person suggesting the idea. The foundation lists must be a safe place where developers can brainstorm without fear of being insulted or flamed.
  • The foundation defines off-topic content as anything included or linked that is:
    • Being used to abuse, harass, stalk or threaten a person or persons
    • Libelous, defamatory, knowingly false or misrepresents another person
    • Infringes upon any copyright, trademark, trade secret or patent of any third party.
    • Violates any obligation of confidentiality
    • Violates the privacy, publicity, moral or any other right of any third party
    • Contains editorial content that has been commissioned and paid for by a third party.

Since most of the foundation's mailing lists are unmoderated lists open to the public, we ask all of our subscribers to help us observe these guidelines. First, by following the guidelines in your own posts. Second, by bringing the guidelines to the attention of anyone who violates one of them. And, third, by ignoring or deleting the posts of subscribers who refuse to observe the guidelines ("Don't feed the trolls").

These guidelines were adapted from the [http://blogher.org/community-guidelines BlogHer Community Guidelines].

Project Guidelines

Each ASF project is entitled to develop and post their own guidelines. As an aid to developing individual project guidelines, here is a set of general project guidelines and ASF practices.

0

Individuals compose the ASF. Our projects must be managed in a collaborative, meritocratic way, so that new volunteers are encouraged to join the project group, and so that the volunteers doing the work are the individuals who make the decisions.

1

PMC members are encouraged to nominate qualified contributors as new committers. ASF members are also encouraged to nominate qualified contributors as new members. Given sufficient time and sustained interest, the set of committers should equal the set of PMC members, and the set of all PMC members should equal the set of ASF members, which together constitute the ASF Community.

2

Merit never expires. "Emeritus" members and committers are welcome to become active participants again, with all prior rights and privileges intact.

3

The mailing lists are a project's only venue for the conduct of business. All development discussions must occur on the project's public mailing lists, or be summarized to the lists, and the project lists must be archived. Development support products, like version control systems, issue trackers, and wikis, should log changes to a public mailing list. Comments posted to a list through development support products are a normal component of development discussions.

4

The project's private list may only be used to discuss pre-disclosure security problems, pre-agreement discussions with third parties that require confidentiality, nominee candidates, or personal conflicts among project personnel, and little else. Discussing development issues on a private list is taboo. Posts to a private list are considered confidential and must not be quoted on public lists without the permission of the author.

5

A project's primary web site and mailing lists must be maintained on ASF hardware. Resources maintained elsewhere are not ASF resources, even if maintained by individuals who happen to be ASF committers.

6

Project source code and documentation must be donated to the ASF under a [http://apache.org/licenses/index.html#clas Contributor's License Agreement]. Donated source code and documentation must carry the ASF copyright and be placed under the Apache License. Code and documentation donated to the ASF must be maintained on ASF hardware. Obtaining a non-exclusive ASF copyright on all material in the ASF repository is encouraged.

7

A PMC member can veto a product change with a technical or legal justification.

8

A release must include the ASF source code being released, binaries are optional. A release vote must be on the actual bits that comprise the release, preferably already digitally signed by a release manager. An ASF release must be approved by at least three members of the PMC and by a majority of the PMC members voting. Approving a release is a development decision. A release cannot be vetoed.

9

Other libraries included with a distribution may be under a different license but must be redistributable under the Apache license.

A

The PMC chair/Project VP must submit regular status reports to the ASF board. The PMC chair is not the project's "leader". ASF projects do not have "lead" developers. Decisions are made jointly by the PMC.

B

[http://tinyurl.com/mw7t6 Author tags] in source code are discouraged but permitted if a PMC so prefers.

ASF Mottos

THIS IS A DRAFT DOCUMENT FOR DISCUSSION PURPOSES ONLY.

This is a list of various ASF mottos, classic and contrived, designed to express the essential principles and practices of ASF Culture. This is an initial draft. Ideally, each motto would include a paragraph or three of explanation.

  • Let them that do the work make the decisions.
  • Merit never expires.
  • Critique our code, not our coders.
  • Put community before code.
  • Let Darwin decide.
  • Give karma where karma is due.
  • Sometimes it's easier to ask for forgiveness than permission.
  • If it didn't happen on a mailing list, it didn't happen.
  • Don't feed the trolls.
  • Thanks for volunteering.

CodeOfConduct (last edited 2009-09-20 23:07:05 by localhost)