I can't attend the governance meeting but I'm +1 on the changes we've discussed.
On Tue, May 4, 2021 at 1:09 PM Oleg Nenashev <[email protected]> wrote: > 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 > <https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLAQQp0ALQQafWzzJsLHsY3V92ok1KCqDwBmNFOMxyWCag%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/CAA0qCNyVi1MVXXCzdSuDrOFsq0Kz%3D26KjFN7%2BePziArjRAF2_g%40mail.gmail.com.
