You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 5, 2024. It is now read-only.
Should we make any further changes to the Maintenance Review process? (JSR 364 already extended the ballot period from one to two weeks to bring it into line with all other ballots.)
The text was updated successfully, but these errors were encountered:
We should address improvement of transparency in the MR process.
Most MRs are done for the purpose of small-scale evolution of previous JSRs, and therefore include API changes. Since the Expert Group for a JSR is dissolved when the JSR completes, there is no formal EG with whom the MR lead consults.
The Process document states (section 3.6.1) "The ML shall consider all requests and shall decide how and if the Specification should be updated in response. The ML is not required to perform these tasks alone, but is free to consult with the former members of the Expert Group, or any other sources, to assist with the Maintenance duties." The implication here is that it is also acceptable for the ML to not consult with EG or other sources.
In my experience, former EG members expect that they will be consulted when an MR is known to be forthcoming for a recent JSR. I think we should formalize some type of requirement for the Lead for a MR (other than for an Errata MR) to consult publicly for feedback on functional changes. While this could be done through comments on JIRA issues, I think it is preferable that a mailing list or some other public forum be used to announce the changes under consideration so that such changes can be discussed and feedback provided before the MR is submitted. When work on an MR is undertaken, there should be some notice of this given on the JSR page (or elsewhere on the JCP site) so that interested members can learn of this work and learn where they can submit feedback on proposed changes before the MR is posted for ballot.
I'd very much second this. For JavaEE 8, there has been absolutely no communication over the publicly accessible mailing lists other than "We're gonna do something, we're gonna tell you about it" followed by another period of radio silence. That could've been prevented with stricter regulations in the area Linda described.
Jira issue originally created by user pcurran:
Should we make any further changes to the Maintenance Review process? (JSR 364 already extended the ballot period from one to two weeks to bring it into line with all other ballots.)
The text was updated successfully, but these errors were encountered: