Skip to content
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

Draft
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

oleg-nenashev
Copy link
Member

JEP-1 was modified according to the discussion in this thread and the Jenkins governance meeting.

Key changes:

  • Replace the former BDFL-driven review and acceptance process by the standard decision making process documented in the Jenkins governance document. The BDFL role does no longer include JEP reviews and decision making.
  • Deprecate the BDFL Delegate role. This change also deprecates JEP-9: How BDFL Delegates, because the delegation is no longer needed.
  • Update Limits of BDFL model reasoning to document the current state and reasons which led to the change.
  • Replace the Sponsor role by Champion
  • Introduce the new Advisor role.
  • Define the minimum 7 calendar days period between the JEP is approved by the Reviewer and transferred to the Accepted state.

After we reach the consensus consensus:

  • Update the role names in the JEP table
  • Add the "Reviewer" column, move the current BDFL delegates there
  • Update the status update scripts to reflect the new summary structure

Copy link
Member

@jglick jglick left a 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.

jep/1/README.adoc Outdated Show resolved Hide resolved
Copy link
Contributor

@bitwiseman bitwiseman left a 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?

jep/1/README.adoc Outdated Show resolved Hide resolved
jep/1/README.adoc Outdated Show resolved Hide resolved
jep/1/README.adoc Outdated Show resolved Hide resolved
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
Copy link
Contributor

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.

Copy link
Member Author

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

Copy link
Contributor

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.

jep/1/README.adoc Outdated Show resolved Hide resolved
jep/1/README.adoc Outdated Show resolved Hide resolved
jep/1/README.adoc Outdated Show resolved Hide resolved
Comment on lines +707 to +713
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.
Copy link
Contributor

@bitwiseman bitwiseman May 6, 2021

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.

@@ -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,
Copy link
Contributor

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.

* 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
Copy link
Contributor

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?

Copy link
Member Author

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?

Copy link
Member

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…

@oleg-nenashev oleg-nenashev changed the title [JEP-1] - Rework the JEP review process and sponsor/BDFL Delegate ter… [JEP-1] - Rework the Jenkins Enhancement Proposal review process, follow the Jenkins open governance proess for decision making May 7, 2021
@oleg-nenashev oleg-nenashev changed the title [JEP-1] - Rework the Jenkins Enhancement Proposal review process, follow the Jenkins open governance proess for decision making [JEP-1] - Rework the Jenkins Enhancement Proposal review process to use the Jenkins open governance decision making May 7, 2021
jep/1/README.adoc Outdated Show resolved Hide resolved
@@ -112,22 +115,14 @@ There are three kinds of JEP:

Copy link
Contributor

@bitwiseman bitwiseman May 7, 2021

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?

Copy link
Member Author

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

jep/1/README.adoc Outdated Show resolved Hide resolved
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".
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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".

Copy link
Member Author

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"

Copy link
Member Author

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 ?

jep/1/README.adoc Outdated Show resolved Hide resolved
oleg-nenashev and others added 2 commits May 9, 2021 00:11
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.
Copy link
Contributor

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.

@bitwiseman
Copy link
Contributor

@oleg-nenashev
I've pushed a commit the moves the change description into the reasoning section. Rather than treating it as a "change history" it describes the reasoning/intent for this change. I also tuned up the rest of the reasoning around BDFL vs consensus. If you disagree with the changes feel free to revert of modify.

Next steps:

  • Determine if BDFL can be removed from the document entirely
  • Rewrite review and acceptance steps of the process to make sense in the context where there is rarely only one reviewer.

@oleg-nenashev
Copy link
Member Author

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

@bitwiseman
Copy link
Contributor

@oleg-nenashev
What is the word on the two next steps above?

@oleg-nenashev
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants