-
-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[JEP-1] - Rework the Jenkins Enhancement Proposal review process to use the Jenkins open governance decision making #359
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems reasonable from a very quick glance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A bunch of suggestions.
I feel like there is still some clean up to be done with dangling references to things that don't work when the BDFL is replaced by the community.
If contributors [the community) believe a decision made by the <> [also generally the community] runs counter to the best interests to Jenkins project,
they may request the <> to review the decision.
Huh?
NOTE: Before May 2021 the term referred to "the BDFL or BDFL Delegate that will review this JEP". | ||
This does no longer apply. | ||
|
||
=== Deprecated terms |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we want to move this to the Reasoning section. Historical info goes there generally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No strong opinion. I can even move it to the Change history section in the bottom. As long as the anchor is preserved, we are fine
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, let's put this under it's own heading in the Reasoning.
If contributors believe a decision made by the <<Reviewer>> runs counter to the best interests to Jenkins project, | ||
they may request the <<Jenkins community>> to review the decision. | ||
Also, they may do in the case of the the overall JEP process disputes (rather than one specific JEP). | ||
The community or, if needed, the Jenkins Governance Board, | ||
will take up the matter and render a decision within a reasonable timeframe. | ||
Similar to the judiciary, the community will _not_ make technical decisions, | ||
they will only affirm or reject the Reviewer's decision. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@oleg-nenashev
This part of the process needs more rewriting. It doesn't really make sense as it stands.
Not sure how to phrase it yet though.
jep/1/README.adoc
Outdated
@@ -1014,31 +1058,39 @@ but that existing RFC was a good justification for keeping the terms. | |||
|
|||
=== Limits of BDFL model | |||
|
|||
People expressed concern over the limits of the current model where the BDFL | |||
During the original discussion of the JEP process in 2017, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to make a new heading for the switch from BDFL and leave this section mostly unchanged.
jep/1/README.adoc
Outdated
* link:https://github.com/jenkinsci/jep/pull/1[PR 1] | ||
* link:https://github.com/jenkinsci/jep/pull/12[PR 12] | ||
* link:https://github.com/jenkinsci/jep/pull/19[PR 19] | ||
* link:https://github.com/jenkinsci/jep/pull/76[PR 76] | ||
|
||
== Change history |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is part of the headings. Maybe put this under "Reasoning?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer to have it in the bottom for process JEPs which may change from time to time. Happy to create a separate PR to the JEP-1 and the template to make it standard. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still prefer to leave it to Git to track exact historical changes. If there are changes to decisions, as in this case, then it makes sense to write them up under Reasoning:
Originally a BDFL was part of this process, but the community switched to a system based on the governance board because…
Co-authored-by: Liam Newman <[email protected]>
@@ -112,22 +115,14 @@ There are three kinds of JEP: | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If BDFL has no responsibilities, do we even need to keep the role?
No offense intended to Kohsuke, but why have a role defined for this process that has no active role in this process?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have contacted KK several days ago about the future of the BDFL role. Just FYI, pending discussion
This decision is made in a publicly traceable form. | ||
Andrea announces the decision in the discussion channel defined for the JEP, | ||
and explicitly sets the final response timeout (see <<accepted>>), | ||
e.g. by saying "this JEP might be accepted in 7 calendar days unless there is unaddressed negative feedback". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
e.g. by saying "this JEP might be accepted in 7 calendar days unless there is unaddressed negative feedback". | |
e.g. by saying "this JEP will be accepted in 7 calendar days unless there is additional feedback". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Commonly we commit on a minimum timeslot. What I am trying to say is that "This change will not be merged before the 7 days timeout, but might be merged shortly afterwards. It might be also merged later due to JEP editor availability or other reasons"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you agree with the comment @bitwiseman ?
Co-authored-by: Liam Newman <[email protected]>
Also tuned the reasoning section to read more smoothly.
should push commits to their fork of the JEP repository footnoteref:[repo], | ||
and submit pull requests targeting the `master` branch. | ||
|
||
[[review]] | ||
==== JEP Review | ||
|
||
Once the sponsor believes a JEP meets at least the minimum criteria to be "<<Accepted, Accepted>>", | ||
Once the champion believes a JEP meets at least the minimum criteria to be "<<Accepted, Accepted>>", | ||
they request the JEP be reviewed for acceptance, usually via | ||
an email to the [email protected] mailing list. | ||
The JEP <<Reviewer>> and their chosen consultants then review the JEP. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes no sense in the new context of generally community consensus for review.
@oleg-nenashev Next steps:
|
Not that I fully agree with this approach @bitwiseman, I believe a changes summary history is very useful for Process JEPs which are designed to be modifiable when needed. At the same time it is not a hill I want to die on, so let's keep it as is. I might come up with Change history proposal as a separate JEP-1 edit |
@oleg-nenashev |
I have a proposal almost ready to go,but I am distracted by personal events, the company-internal priorities and the contributor summit. I hope to return to it in July, no promises. CC @MarkEWaite |
JEP-1 was modified according to the discussion in this thread and the Jenkins governance meeting.
Key changes:
After we reach the consensus consensus: