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 <https://github.com/jenkinsci/jep/tree/master/jep/1#motivation> - 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. On Mon, May 3, 2021 at 2:15 AM Oleg Nenashev <[email protected]> wrote: > 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 > <https://en.wikipedia.org/wiki/Benevolent_dictator_for_life> 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 > > On Wednesday, January 29, 2020 at 3:35:54 PM UTC+1 [email protected] > wrote: > >> On Mon, Jan 27, 2020 at 2:55 PM Jesse Glick <[email protected]> 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. >> >> -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/a618acee-e4f7-4ae9-b182-7a8141564b44n%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-dev/a618acee-e4f7-4ae9-b182-7a8141564b44n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAA0qCNxy6oUxv-Sh8PeVc0WPm-akaSvfPCWPiCTyRycpgixOkA%40mail.gmail.com.
