GWT Project Steering Committee Meeting Notes - June 10, 2020

[Colin Alworth]

Hello GWT - as hinted at by Goktug's email this past week, we're trying to improve how the steering committee operates and communicates. Yesterday's meeting was entirely about this. Note that as a result of meeting about meeting, some of this email may feel a little bit meta or repetitive.

What follows is a brief summary of what was discussed. Nothing was concretely decided, these separate items will be put up for discussion in separate threads. Steering committee members, please start discussions as you see fit or reply to existing discussions to vote - if you do not have access to post to this list, email me directly and I'll fix that.

---

Present Goktug, Mark, Justin, Colin, Dmitrii, Frank, Julien

Goktug has prompted us to clarify the role, makeup, responsibilities of the GWT Steering Committee

First suggestion was to look into apache/eclipse organizations - we’ll put that out on the gwt-contrib mailing list once we have some basics worked out. Colin noted that previously the committee has rejected the idea not due to any specific downsides, but since the accompanying management overhead might be more than we were interested in. This is not to say it is a bad idea, just that it was previously rejected (circa 2015). Replacing current processes by adopting another org's pro

• Frank did some brief initial work into looking at Eclipse org, appears we would need to change license, which probably doesn't make sense.
• We're seeing a volunteer to evaluate and present options around the Apache Software Foundation, or some other organization.

"Refresh" the gwt steering committee and its processes:

• What do we expect from the steering committee, what problems does it solve, what is discussed when they meet?

• Technical topics, discussions in public, prompted by maintainers on the gwt-contrib mailing list, default to following what that discussion comes up with by stakeholders and the people who are putting the time in to achieve those ends, if we run into conflicts, we can raise to SC level to handle it. Favor practicality over feasibility.

• SC is here to solve governance and policy problems, not technical ones. Handles conflicts not solved at “lower” day to day levels

• How do we communicate?

• Meetings should occur not less often than every 6 mos - agenda items may accumulate, but expect them to be resolved via publicly-readable mailing list. Meeting times will be decided per meeting, at least a week in advance, to allow anyone interested in joining to adjust the time so they can be available.

• Notes from calls will be published on the gwt-steering mailing list and also on gwtproject.org

• Meetings are the venue for discussion, not voting on a decision, which happens instead on the mailing list

• How does membership work

• Take this time to refresh, update published list: Proposal sent to all potentially active members to “join the meeting or respond to the email to indicate active participation within some period of time.” One week to respond, Colin will reach out again publicly and privately, one week after that and only those who have responded positively will be part of the committee.

• Being a member of the committee doesn’t itself confer any rights, the committee itself is what grants these

• No response to two policy discussions indicates that you are no longer interested in being involved. Response can be as simple as “I don’t have an opinion” (which implies “yes, this should proceed”, since we operate by consensus). If no decision needs to be made, not joining/responding to two meeting invites indicates that you are no longer interested in being involved (where again, responding can be “no, I am not available, but am still interested in being involved”)

• Management of resources (website/hosting/dns, maven central groupid, opencollective, etc)

• Proposals should be put to the gwt-steering mailing list

• Issue currently on the table is management of gwtproject.org, to be discussed separately, voted on in the mailing list, Colin will post this.
  

• Release

• Will be managed by someone selected by the committee (so that they have access to org.gwtproject groupid in sonatype), and planned/discussed in gwt-contrib mailing list

• Release criteria will be discussed and approved by gwt-contrib list, releases must meet these criteria. Frank will finalize this document, put it up for review soon.

This is not the final set of policies - I will soon finish a draft of this to be discussed, voted on in a separate thread. We will however provisionally adopt these guidelines to discuss the policy and adopt it (unless we vote instead for paradox and do not adopt the process which created the process?).

Please reply to add anything else missed from this meeting, or to acknowledge that you still plan to participate in the steering committee.

[Thomas Broyer]

Fwiw, the original "purpose and charter" from 8 years ago (to the day!), during our first meeting: https://docs.google.com/document/d/1QL3YAm01K2YBoqLg4sTBLXqMgHvwnhUS0P5EwzJ7FG0/edit?usp=sharing

(I checked and the link had already been posted here earlier)

[Colin Alworth]

Thanks! I'll put a few notes at the bottom of the draft doc to contrast to this. I will note that this doesn't appear to be a doc that was adopted, but discussion on what to adopt - for example under decision making process it indicates that there are two options to decide, what google suggests, and a special case for removing a member, but no actual "this is how the committee will make decisions" note is there. That is instead found at http://www.gwtproject.org/steering.html, and possibly other places.

[Thomas Broyer]

There are actually comments in the doc stating "motion carried" everywhere (and "motion carried, renamed to gwt-steering@" about the mailing list, and "absolutely carried" about the switch to Git), but they're not publicly visible. I just added you to the doc so you can see them.