Thanks! I will create a pull request for the JEP tomorrow. No laptop at the moment
On Tue, May 4, 2021, 21:44 Liam Newman <[email protected]> wrote: > 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 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/CAA0qCNwKHfzhJh4mfnuc%2BU0aCcSXJ1hv2dd25ZUzgxiFtV2NTg%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAA0qCNwKHfzhJh4mfnuc%2BU0aCcSXJ1hv2dd25ZUzgxiFtV2NTg%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/CAPfivLAQQp0ALQQafWzzJsLHsY3V92ok1KCqDwBmNFOMxyWCag%40mail.gmail.com.
