All this sounds good to me. Thanks for working on this. -L.
On Tue, May 4, 2021 at 10:00 AM Oleg Nenashev <[email protected]> wrote: > 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 > > > > > On Tuesday, May 4, 2021 at 5:49:03 PM UTC+2 [email protected] wrote: > >> 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. >> >> >> >> >> >> On Mon, May 3, 2021 at 2:16 PM Oleg Nenashev <[email protected]> wrote: >> >>> 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 >>> >>> >>> On Mon, May 3, 2021 at 10:52 PM Liam Newman <[email protected]> wrote: >>> >>>> 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 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 >>>> [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAA0qCNxy6oUxv-Sh8PeVc0WPm-akaSvfPCWPiCTyRycpgixOkA%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAA0qCNxy6oUxv-Sh8PeVc0WPm-akaSvfPCWPiCTyRycpgixOkA%40mail.gmail.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/CAPfivLDhhoQiry82r4edquLnNv21J%3DaN3xvZiXfx-p4_bBVe%2BA%40mail.gmail.com >>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDhhoQiry82r4edquLnNv21J%3DaN3xvZiXfx-p4_bBVe%2BA%40mail.gmail.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/37edb933-8ae7-4d4c-a187-82499d40b9a7n%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-dev/37edb933-8ae7-4d4c-a187-82499d40b9a7n%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/CAA0qCNwKHfzhJh4mfnuc%2BU0aCcSXJ1hv2dd25ZUzgxiFtV2NTg%40mail.gmail.com.
