JEPs & BDFL ~ KK

[Jesse Glick]

Shall

https://github.com/jenkinsci/jep/tree/master/jep/1#bdfl

be amended somehow, to not assume KK has time to get involved? For
example to cut out the BDFL layer between JEP editors/reviewers and
the governance meeting? Also

https://github.com/jenkinsci/jep/tree/master/jep/9#specification

As a practical matter,

https://github.com/jenkinsci/jep/tree/master/jep/1#jep-review

has never been followed very consistently in my experience;
implementations get merged and released following regular hosting
and/or code review processes, while the JEP is still officially a
“draft”, and the “accepted” and “final” phases are skipped or a
formality. Maybe it is time for a streamlined process.

[Kohsuke Kawaguchi]

A part of the original JEP was to design an aspirational collaboration process that we wanted to promote back then, and use the power of the process to achieve that. I feel like the situation and the priority has changed a little since then.

What I mentioned to a few people on various occasions is that IMHO our current priority should be more on enabling existing doers to make impactful changes more easily, less on empowering new contributors to lead significant changes on their own.

So from that perspective, tweaking JEP to reflect how things are working in practice is a great idea. That's what I assume you meant by "streamlined process."

(That said, what I hate the most is for people to spend lots of time discussing how the process should be tweaked. That to me is the most counter productive!)

My 2 cents.

--

Kohsuke Kawaguchi

[Oleg Nenashev]

RE: "JEP-1 has never been followed very consistently in my experience. implementations get merged and released following regular hosting and/or code review processes". Let's face the reality, the JEP process is rather dead than alive at the moment. It is quite heavy to be followed, and right now it does not achieve its main purpose - facilitate the community feedback, help JEP submitters to get their changes delivered, and to ensure that all changes are net-positive for the Jenkins project and beneficial for Jenkins users down the line. Current process is quite heavy, and delays in JEP stages (e.g. BDFL Delegate delegation requires a direct message to KK to happen) defeat the purpose of JEPs. We want to help contributions, not to block changes by raising extra barriers. Be sure that contributors already have enough obstacles which block them from contributing to the project.

What is my approach w.r.t. JEPs as a core maintainer?

• Consensus in the developer mailing list is a priority for me: feasibility, community value, design. If there is such consensus and no major concerns, JEP is NOT needed at all
• JEP is a way to document the discussion feedback and agreements: discovered issues, concerns. It includes the feasibility, architecture/implementation and, last but not least, the rollout plan
• If there is consensus in the dev list && Reference implementations get enough reviews, I am happy to deliver changes which are formally in draft. We have some tools for it:
• "@Restricted(Beta.class)" for API changes
• Changelogs/documentation - features can be documented as experimental
• // The tools do not address all cases, but
• If there are conflicting/intersecting proposals (e.g. JEP-223 and JEP-224), use mailing lists and JEPs as a way to discuss the proposals and to agree on the next steps

I am in favor of updating the JEP process a bit so that it becomes easier for contributors to deliver changes. It would be also great if it gets the BDLF out of the hook there so that he can focus on more important subjects. 

• Update the JEP process to be auxiliary addition to developer list discussions, not the main venue to discuss all major changes as it is documented now. JEP process is followed if there is no consensus OR there is major impact on users (breaking changes)
• remove the "BDFL Layer" in the initial draft review. As Jesse said, the "BDFL layer between JEP editors/reviewers and the governance meeting" does not look to be efficient at the moment. With the Governance Board recovered, delegation of the "BDFL Delegate" role could be done by the board or by the governance meeting so that 
• Change the terminology to reflect the current state, similar to what KK says about changing the priorities for the JEP process
• Add an "Author" role to JEP. This role represents JEP submitter and ones who implement it (part of the current "Sponsor role")
• Merhge the remaining parts of the "Sponsor" role and "BDFL Delegate" to have a new "Sponsor" role: "an experienced contributor who helps the proposal to happen: ensure there is enough feedback and that all comments'concerns are addressed"
• // Such change would also address my concern that "Sponsor" and "BDFL delegate" are the same person in many cases, which defeats the purpose of peer reviews. With an experienced contributors, IMO it is perfectly fine to have them as Sponsors 
• Modify JEP stages to focus on the feature delivery process instead of the document review
• Draft - there is a consensus in the community that it worth prototyping, but the details are under discussion && the implementation is not finalized.
• Preview - the JEP is available as an experimental feature (opt-in, protected by feature flags and/or Beta API)
• Delivered - the majority of the JEP scope is delivered. Minor leftovers may stay around

 

Sorry if I spend too much time discussing it :)

BR, Oleg

[Jesse Glick]

On Sun, Jan 26, 2020 at 4:28 PM Oleg Nenashev <o.v.ne...@gmail.com> wrote:
> [the JEP process] does not achieve its main purpose - facilitate the community feedback, help JEP submitters to get their changes delivered, and to ensure that all changes are net-positive for the Jenkins project and beneficial for Jenkins users down the line.
> …

> JEP process is followed if there is no consensus OR there is major impact on users (breaking changes)

I would draw the line very differently and say that the JEP _process_
is not so important as the JEP itself: it is a single clear document
explaining to future generations how a particular major design
decision in Jenkins was made and why, all with an easily remembered
handle “JEP-456”. There need not be any breaking changes involved or
lack of consensus. In fact if there is no consensus then there is no
point in having a numbered JEP at all: you should first work to refine
your idea with skeptics, or just defer it. (File a draft PR if you
want something to refer to.)

Echoing KK (I think!), JEP should be a tool which assists people who
are already comfortable working on Jenkins. Keep the “editor” role,
responsible for matters of form and administration; and merge
“sponsor”, “contributors”, “BDFL”, “BDFL delegate”, and “reviewer”
into a simple “author” who is responsible for submitting the JEP,
doing the implementation, and delivering it, or delegating pieces of
this as they see fit. The board would just be a last resort in case
someone is trying to push through an unpopular change, with or without
a JEP.

[Daniel Beck]

On Mon, Jan 27, 2020 at 2:55 PM Jesse Glick <jgl...@cloudbees.com> wrote:

Echoing KK (I think!), JEP should be a tool which assists people who
are already comfortable working on Jenkins. Keep the “editor” role,
responsible for matters of form and administration; and merge
“sponsor”, “contributors”, “BDFL”, “BDFL delegate”, and “reviewer”
into a simple “author” who is responsible for submitting the JEP,
doing the implementation, and delivering it, or delegating pieces of
this as they see fit. The board would just be a last resort in case
someone is trying to push through an unpopular change, with or without
a JEP.

I remember it as a tool to help especially less experienced contributors (from a governance/community involvement POV) get larger scale changes in without them lingering in review forever or being rejected at the last step, wasting a lot of time.

I don't know how well it worked for that use case but we should work towards enabling such work rather than just make it a place where "the regular suspects" document their major changes.

[Oleg Nenashev]

Hi all,

I am not sure this is the last conversation about the JEPs process, but as a JEP Editor I would like to recover it. Currently the JEP process does NOT workm neither for the original inspiration s nor for the documentation purposes. We have multiple JEPs created recently, but they get stuck overall. Thanks to Jesse, Daniel Beck, Wadeck, Sumit Sarin and Tim Jacomb for the recent JEP updates. It is important to keep doing so, but it is important to have the process more lightweight and active.

To address the JEP stagnation issue, I suggest the following changes:

• We remove the "BDFL" and ""BDFL Delegate" concepts from the JEP process. Instead of that, the Jenkins governance process applies. The "acceptance" decision is made by a consensus in the mailing list or voting at the governance meeting. These entities can also delegate the final decision to another group (e.g. SIG) or individual contributor
  • Note: JEP-1 is the only place where the Jenkins BDFL role is used. If Kohsuke agrees, we could abolish this role similarly to what the Python community did. Kohsuke will always remain the Founder of Jenkins, and this is the role which will stay forever. Kohsuke will also remain the permanent member of the Jenkins Governance Board until he decides to step down
    
• At one of the next Governance meetings, we do a bulk review of the JEPs and approve changing status for those which were de-facto delivered (e.g., Remoting over Websockets by Jesse).
  
• We extend the team of JEP Editors and add experienced JEP contributors there, e.g. Jesse Glick, Daniel Beck, Tim Jacomb

To simplify the process, I also suggest the following:

• We introduce the "JEP Champion" (or "JEP Owner") term. It is basically how we handle "Sponsors" in JEP-1 now. This role lists all contributors driving the JEP discussion and delivery, including the original author. Champions may be added as the JEP evolves.
  • Note: I do not suggest "JEP Author" or "JEP Contributor", because we target wide feedback and contributions from many participants. We have a Git history for that. 
    
• We introduce a new optional "JEP Sponsor" column. This is used in the case when a less experienced contributor submits a JEP and becomes a JEP champion. A sponsor is a nominated or a self-nominated experienced contributor who helps the champion(s) do go through the JEP process and, particularly, to ensure there is a public discussion and a consensus built around accepting the JEP, and thaen the Governance decision making process. 

The changes will need explicit approval from Kohsuke, but I believe we have his support for the process update part. Abolishing the BDFL term is a separate topic which does not block the JEP process update.

Best regards,

Oleg Nenashev

[Liam Newman]

As one of the "Sponsors" of JEP-1, I should probably weigh in.  

I support streamlining the JEP process any way the community sees fit to do.  Removing the BDFL and BDFL Delegate, replacing them with the Governance Board certainly makes sense at this point.  Howver, I don't like changing the meaning of existing terms unless it makes the process significantly clearer going forward.  In the case changing "Sponsor" -> "Champion/Owner" and adding "(New role) Sponsor", I'm not convinced there's a huge win there.  We already define a "Reviewer" role as an alias for "BDFL and BDFL Delegate".   If we replace the "BDFL Delegate" field with "Reivewer" wouldn't that be sufficient?  It would be significantly less confusing than changing the meaning of an existing term. 

As for the other changes, I suggest folks reread the Motivation for JEP-1 - one of the main goals of the process is to document how decisions were reached.  Switching to "focus on the feature delivery process" misses the point - creating and updating the JEP document should be part of the feature delivery process. Encouraging consensus-driven design, tracking current design state and discussion, and documenting the reasons various design decisions were made is vital not only to lowering the barrier to entry for new contributors, but also to improving the velocity of updates and improvements.  

I understand creating and maintaining these kinds of documents is hard. I have at least two features I've implemented that should have JEPs and do not yet. Shame on me. However, I still think it is important to not "streamline" away key parts of why we have JEPs in the first place. It is better to have a slightly heavier process that isn't always done perfectly than to have a lighter process that doesn't achieve what it was intended to.

Oleg, perhaps you could submit a PR (or more than one) with proposed changes?

-L. 

 

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/a618acee-e4f7-4ae9-b182-7a8141564b44n%40googlegroups.com.

[Oleg Nenashev]

In the case changing "Sponsor" -> "Champion/Owner" and adding "(New role) Sponsor", I'm not convinced there's a huge win there.  We already define a "Reviewer" role as an alias for "BDFL and BDFL Delegate".   If we replace the "BDFL Delegate" field with "Reivewer" wouldn't that be sufficient?  It would be significantly less confusing than changing the meaning of an existing term. 

Might be. I just wanted to align the "sponsor" term with how it is used in other projects. In our case "sponsors/JEP-1" are de-facto authors. Maybe a one-time term change would be less confusing for 3rd parties in the future.

For "Reviewer", this is not exactly what I propose. IMO every interested party is expected to review a JEP. The job of the suggested "sponsor" role is to help the authors with the process and with getting the required community feedback, not necessarily to review the entire JEP and technical merits on their own.

Oleg, perhaps you could submit a PR (or more than one) with proposed changes?

It would be great to reach the consensus first. Then yes, I will submit the JEP update

 

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/hepntz6WZak/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAA0qCNxy6oUxv-Sh8PeVc0WPm-akaSvfPCWPiCTyRycpgixOkA%40mail.gmail.com.

[Liam Newman]

Oleg, 

I agree that the names of the roles matter and "Champion/Owner" definitely is more descriptive. 

My main concern is confusion around the repurposing of the term "Sponsor".  I would agree to this if we can avoid name collision.  What about "Advisor" or "Mentor"?

Everyone should review JEPs they are involved in, but there still needs to be an explicit list of "Reviewers" that sign off on a JEP. 

I look forward to feedback from others on this thread. 

-L. 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDhhoQiry82r4edquLnNv21J%3DaN3xvZiXfx-p4_bBVe%2BA%40mail.gmail.com.

[Oleg Nenashev]

Hi Liam,

"Advisor" looks good to me. Although we would not be using the same terminology as in Java JEPs, I agree using this name would help. So I would prefer to choose the "Champion/Advisor" pair then.

For sign-off, I think that the standard Jenkins open governance process allows that:

• The Jenkins Developer mailing list provides a trace of those who sign-off the proposal asynchronously
• The Governance meeting agenda and recording keep trace of votes at the Governance meeting. We can communicate them back to the developer mailing list explicitly
• If a decision is delegated to an entity like SIG, it is again traceable on its level
• If a decision is delegated to a single contributor, this contributor becomes that "reviewer"

The main problem with this process is versioning. What if the proposal gets changed during the approval process? How do we track that and whether the borderline between small change and one requiring re-approvals? I do not have exact answer to this. What we could do is the "ready to publish" state:

• When a proposal is approved at the "open governance process", a pull request is submitted to transfer the proposal to the Active/Accepted/Final state
• There is a timeout similar to "ready-for-merge" in the Jenkins core PRs. If there is no negative feedback until the timeout, the proposal gets merged. The timeout time is TBD, but I would not like it to be more than 1 week
  
• JEP Champions or an Advisor are expected to explicitly communicate the merge countdown in the discussion thread
  

What do you think?

Best regards,

Oleg

[Liam Newman]

All this sounds good to me.  Thanks for working on this.

-L. 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/37edb933-8ae7-4d4c-a187-82499d40b9a7n%40googlegroups.com.

[Oleg Nenashev]

Thanks! I will create a pull request for the JEP tomorrow. No laptop at the moment

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAA0qCNwKHfzhJh4mfnuc%2BU0aCcSXJ1hv2dd25ZUzgxiFtV2NTg%40mail.gmail.com.

[Liam Newman]

I can't attend the governance meeting but I'm +1 on the changes we've discussed. 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLAQQp0ALQQafWzzJsLHsY3V92ok1KCqDwBmNFOMxyWCag%40mail.gmail.com.

[Liam Newman]

Oleg, 

I just thought of one more possible change.  Instead of having proposed JEPs sit as PRs until they meet the bar for "Draft", we should add a "sandbox" folder with named subfolders. So instead of having one pre-draft folder "0000" we can have many.  This would allow people to more easily collaborate on getting JEPs to Draft state.  Alternatively, we could have a jep-sandbox fork that holds the JEP sandbox (keeping the jep repo cleaner). That repo would have a wiki-style editing policy with a very low bar for getting contributor status, letting people make changes without PRs.

-L. 

[Jesse Glick]

On Wed, May 5, 2021 at 2:44 PM Liam Newman <bitwi...@gmail.com> wrote:

Instead of having proposed JEPs sit as PRs until they meet the bar for "Draft"

It is a pretty low bar I think. You just have to finish writing what you plan to do.

 

This would allow people to more easily collaborate on getting JEPs to Draft state.

If there are truly multiple authors writing content, there are already plenty of ways for people to collaboratively draft documents. YAGNI?

[Oleg Nenashev]

I suggest landing the already agreed changes first. I see merits in some 0000 redesign, but I would not like to block other changes by that

--

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/hepntz6WZak/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr20tELavC%2BSEb1b2sKSMMHthWWhgZXm3YC%3DuGMtcrCvWQ%40mail.gmail.com.

[Oleg Nenashev]

Hi all,

We have not reached the JEP topic at the yesterday's governance meeting. At the same time, I went ahead and tried to implement what seemed to be a consensus to me in this discussion: https://github.com/jenkinsci/jep/pull/359 . After some consideration I put 3 roles in the JEP:

• Champion
• Advisor - optional, as discussed above
  
• Reviewer - defaults to the Jenkins community and the standard Governance process, unless the community delegates the review and the final decision to another entity.
  

Note that we will need KK's approval for this changes as BDFL, but firstly I'd like to ensure we have a consensus in the proposal. I have also reached out to Kohsuke to check with him regarding the BDFL role and wjhether we should deprecate it, but for now I kept it as an active role withouut any responsibilities or priviliges.

Any feedback will be appreciated.

Best regards,

Oleg Nenashev