An open ecosystem based on standards and interoperable reference implementations requires active discussions, comprehensive specifications, and collaborative code development. To establish a solid foundation for discussion, specification, and development, this set of guidelines lays out the manner and approach we should encourage to maximize our effectiveness and ensure we incorporate the input of all who seek to contribute.
For all phases of interaction described within, participants will rigorously apply three key principles to ensure forward motion:
Silence is Assent: If you are silent, absent, or fail to participate in a discussion, meeting, or decision making process, you agree and accept the outcomes and decisions of those who did.
Disagree and Commit: If a decision is made that you don't like, accept that the point is settled, register your disagreement in a constructive way, and commit to dutifully proceeding as a team player to realize the plan.
Code Speaks the Loudest: While all forms of feedback should be treated as valuable contributions, the delivery of code that backs up a position with positive forward motion should carry the most weight.
The three sections below represent the major phases members and groups engage in to deliver the the outputs they seek. While the directions and guidelines found in these sections are not meant as rigid, legalistic mandates, they are suggestions that should be followed whenever possible, and members should hold each other accountable for living up to the ideals they promote.
In the exploratory phase that proceeds spec development, groups should actively engage each other across group and organizational lines in discussion, debate, and ideation. People should be free to discuss ideas without fear of exaggerated negative responses or an idea must be perfect before it can see the light of day. The following behaviors should be the default for interactions during this phase:
- Communicate ideas early and often - don't build a massive stack of assumptions or wait until you have crafted what you believe is The Perfect Proposal.
- Make an active effort to include others - hold discussions in open forums, invite commentary, and welcome opposing feedback.
- Timebox discussion and debate - actively avoid stagnation by setting reasonable timeboxes for discussion, debate, and exploration, and commit to a practical choice if time expires.
During the specification phase, members should make an effort to gain consensus agreement on the following checklist of items that may pertain to the project or technical work they are specifying:
- Goal of the spec
- The scope of the spec, and any explicit exclusions
- Features and relative priority for inclusion
- Identify the high-level MUST/NOT, SHOULD/NOT, MAY/NOT, RECOMMENDED, and OPTIONAL
- Identify any known or suspected security implications
- Check with other Working Groups and the membership to ensure we covered everything
All substantive, long-form technical discussion/debate about what to add to a spec, and the consideration of options for doing so, should be reflected in Github Issue threads. This is to ensure that other WG members and outside observers have a chance to read, interact, and understand the details behind why a decision or feature is being specified the way it is.
Collaborating on a shared piece of code across organizations, distances, and differing points of view can be quite challenging. This section of the process, more than perhaps any other, benefits from open, inclusive, incremental efforts that allow each member to have a clear view of where they can best contributed.
There are three key process commitments members should make to themselves and each other to help ensure high quality work that includes the contributions of all stakeholders:
- Write proposals and get buy-in - implementation of major features and component areas should be preceded by one or more proposals. Proposals should be seen as a positive opportunity to review and vet ideas about how to approach a body of work, with the ultimate goal being consensus support to proceed with whatever revision of the proposal the group accepts.
- Make an effort to share the load - if several groups are interested in participating in development of a component, feature, or facet of the implementation, make an active effort to segment and share the load. Contributors and their desire to add value should be welcomed by all in the group, and group members should take the time to answer any questions or comments when they engage.
- Land code early and often - in keeping with a core principle of healthy open source collaboration, don't go off as a single member (or organization) and develop fully baked implementations of components, features, or other development items, then drop massive Pull Requests on the group. Instead, make frequent, small commits that everyone can see, understand, and collaborate on.
Be considerate, caring, and charitable in your interactions with others. We are all trying to push the ecosystem forward the best we can, so treat others the way you would like to be treated.