Discussion on adopting new policy on the role of the GWT Steering Comittee

[Colin Alworth]

As in my last email, we will discuss and vote on this document as if it were already adopted. If adopted, this document will be published on gwtproject.org, where other policy documents should be made available as well. Presently, http://www.gwtproject.org/steering.html describes the makeup and format of the committee, and https://docs.google.com/document/d/1QL3YAm01K2YBoqLg4sTBLXqMgHvwnhUS0P5EwzJ7FG0/edit#heading=h.7rqrfz6ivw7r describes Google's initial vision and goal for the committee. The primary distinction with the below text vs Google's initial proposal is that being a Steering Committee member does _not_ automatically grant committer access, that will be governed separately, probably though the gwt-contributors side of things? Where there is conflict with the initial document, it is my suggestion that the new document prevails. In any case, points from the old document should be carried forward and made public on the website.

Here's my first draft of a writeup - this is an attempt to distill the discussion yesterday into prose, so may have some mistranslations, or members who were unable to attend may have other thoughts around this re-imagining process.

Introduction

The GWT Project Steering Committee exists to manage the high level processes of the project - discussing and formalizing policy that guides how the project goes about its work. The committee’s members are active participants in the development community who have an interest in guiding policy as well as helping in improving the ecosystem. Decisions are made by consensus, requiring that all members agree to enact a change. 

Membership

Maintaining membership thus requires participation in discussions and votes as they arise, no response to two policy discussions indicates that you are no longer interested in being involved. Responses can be as simple as “I have no opinion”, though this is equivalent to agreeing with the discussion at hand. Since while there may be a long period with no discussion, there is also a need to ensure that members are active when a discussion does take place, so meetings by video call will happen not less than twice per year, though a meeting with no agenda will be brief to respect everyone’s time. Any scheduled video call meeting will be planned at least a week in advance to give everyone a chance to adjust the time so they can participate. As with discussions, responding to a meeting invite can be as simple as “I cannot attend, but I am still interested in participating” to stay active. New members can be proposed by current members and voted in as with other policy changes.

Discussions

Discussions within this group should be confined to policy topics - technical discussions should always take place in a more general venue like an issue tracker or the gwt-contributors mailing list. Generally speaking, discussions will take place on the gwt-steering mailing list, if face-to-face interaction isn’t required. Meetings will occasionally serve as a “face to face” discussion mechanism, providing higher bandwidth back-and-forth of ideas, but will not be used for decision making and voting. Notes taken during any call should be published to both the gwt-steering list and to the project website within 2 business days of the meeting. When those notes are published, this will be the opportunity for members who weren’t able to attend to be informed and continue discussion, and prepare for a vote.

Voting

Voting takes place on the mailing list. There is yet no formal way to declare that discussion is complete and voting should begin, nor is there a specific timeframe required to vote in. At this time I suggest that we do not have a requirement/action indicating that voting must start (this can be changed later), but that voting must be done within three business days of the discussion being moved to a vote, so that changes can be enacted promptly once a proposal is complete.

Allocating GWT Project Resources

Being a member of the steering committee itself does not grant any specific rights, instead it is the committee itself which grants these rights. That said, many resources are owned or controlled by individual members, or the organizations to which those members belong, as there is no legal entity which represents the GWT Project at this time. Those members or their organizations are entrusted to manage these resources on behalf of the whole project, and to return or relinquish resources at the committee’s discretion. Examples of these resources include:

• Gwtproject.org domain name (and hosting resources)

• Access to org.gwtproject groupId in sonatype’s infrastructure for maven central

• Opencollective-collected funds

• github.org/gwtproject, gitter.im/gwtproject organization

• Mailing list moderation

Release Process

While the content of a release is expected to be managed as a technical topic by the gwt-contributors mailing list, actually performing a release requires access to project resources like the org.gwtproject groupId. As releases to Maven Central are irreversible, these will be treated somewhat differently than regular development work. Release guidelines and criteria will be created and published, and release managers selected through the steering committee’s processes and policies to administer these releases, ensure they follow the guidelines.

[Colin Alworth]

Seeing no feedback on this, I'll take a quick shot at merging this and the contents of https://docs.google.com/document/d/1QL3YAm01K2YBoqLg4sTBLXqMgHvwnhUS0P5EwzJ7FG0/edit into a single document, and put it up for a vote. As there hasn't been any feedback, I'm assuming that there is no objection to the basic ideas here or to the changes being made to the earlier document, and that we expect to pass this as-is.