Differences between revisions 9 and 10
Revision 9 as of 2007-06-27 12:39:20
Size: 9885
Editor: cpe-66-67-122-162
Comment: Add anchor links
Revision 10 as of 2007-06-29 01:54:46
Size: 9926
Editor: c-24-6-172-77
Comment: typographic and/or grammatical changes (mostly)
Deletions are marked like this. Additions are marked like this.
Line 10: Line 10:
The Apache Software Foundation creates and maintains open source software products for the public benefit utilizing a collaborative, meritocractic 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. The Apache Software Foundation creates and maintains open source software products for the public benefit utilizing a collaborative, meritocractic approach to software development. Our products are developed by a diverse community of volunteers, a large number of whom use our software products in the course of their own daily lives. Our development discussions are held on 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.
Line 16: Line 16:
 * 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 personal attacks as "criticizing the coder rather than the code". While it is acceptable (indeed, encouraged) 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.
Line 18: Line 18:
 * 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
 * The foundation defines off-topic content as anything included or linked that:
   * Is used to abuse, harass, stalk or threaten a person or persons;
   * Is 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; or
Line 26: Line 26:
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"). 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 their 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").
Line 43: Line 43:
|| 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. || || 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. ||
Line 91: Line 91:
|| Let them that do the work make the decisions. || self-determination || || Let they that do the work make the decisions. || self-determination ||

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 materials. Whether or not the foundation should have such a code has not been determined.

THESE ARE DRAFT DOCUMENTS FOR DISCUSSION PURPOSES ONLY.

Anchor(community-guidelines)

Community Guidelines

THIS IS A DRAFT DOCUMENT FOR DISCUSSION PURPOSES ONLY.

The Apache Software Foundation creates and maintains open source software products for the public benefit utilizing a collaborative, meritocractic approach to software development. Our products are developed by a diverse community of volunteers, a large number of whom use our software products in the course of their own daily lives. Our development discussions are held on 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.

  • 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". While it is acceptable (indeed, encouraged) 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 used to abuse, harass, stalk or threaten a person or persons;
    • Is 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; or
    • 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 their 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].

Anchor(project-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.

Anchor(asf-culture)

ASF Culture

THIS IS A DRAFT DOCUMENT FOR DISCUSSION PURPOSES ONLY.

We usually refer to our software methodology as the "Apache Way", which we describe in terms of six hallmarks

  • collaborative software development
  • commercial-friendly standard license
  • consistently high quality software
  • respectful, honest, technical-based interaction
  • faithful implementation of standards
  • security as a mandatory feature

Taken together, these six hallmarks work together to serve the implicit ASF prime directive

  • Foster a collaborative approach to software development

Likewise, each ASF project has an implicit prime directive to

  • Create and maintain the software that we ourselves want to use

Underlying the six hallmarks and our prime directives are a set of five fundamental values that embody the ASF Culture.

  • collaboration
  • self-determination
  • transparency
  • sustained interest
  • netiquette (or common courtesy)

We usually express these values in the form of mottos or pity sayings.

Anchor(asf-mottos)

ASF Mottos

THIS IS A DRAFT DOCUMENT FOR DISCUSSION PURPOSES ONLY.

Part of the ASF Culture is to speak to each other in mottos. We use these mottos in much the same way that architects use design patterns.

(This is an initial draft. Ideally, each motto would include a paragraph or three of explanation. )

Motto

Core Value

Put community before code.

collaboration

Let they that do the work make the decisions.

self-determination

If it didn't happen on a mailing list, it didn't happen.

transparency

Merit never expires.

sustained interest

Critique our code, not our coders.

netiquette

Motto

Core Value

Thanks for volunteering.

self-determination

To become a committer, act like a committer.

self-determination

Give karma where karma is due.

self-determination

Let Darwin decide.

self-determination

Sometimes it's easier to ask for forgiveness than permission.

self-determination

Motto

Core Value

Don't feed the trolls.

netiquette

Anchor(other-asf-conventions)

Other ASF Conventions

THIS IS A DRAFT DOCUMENT FOR DISCUSSION PURPOSES ONLY.

Motto

Core Value

Discuss controversial commits before committing.

collaboration

Do not revert a commit without due notice and a proper veto.

collaboration

Let us know when you can help. Also let us know when you can't help.

collaboration

Be the volunteer of last resort.

collaboration

Group stylistic changes and operational changes into separate commits.

collaboration

Chunk commits but avoid churn.

collaboration

If a thread heats up, meter replies to one a day.

collaboration

Motto

Core Value

First, scratch your own itch.

self-determination

Motto

Core Value

Encourage smart questions.

netiquette

Security is a mandatory feature.

netiquette

Anchor(see-also)

See Also

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