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 <o.v.nenas...@gmail.com> 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 <bitwise...@gmail.com> wrote: > >> All this sounds good to me. Thanks for working on this. >> -L. >> >> >> On Tue, May 4, 2021 at 10:00 AM Oleg Nenashev <o.v.nenas...@gmail.com> >> 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 bitwi...@gmail.com 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 <o.v.ne...@gmail.com> >>>> 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 <bitwi...@gmail.com> >>>>> 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 <o.v.ne...@gmail.com> >>>>>> 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 >>>>>>> db...@cloudbees.com wrote: >>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> -- >>>>>>> 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 >>>>>>> <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 >>>>>> 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 >>>>>> <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 jenkinsci-de...@googlegroups.com. >>>>> >>>> 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 jenkinsci-dev+unsubscr...@googlegroups.com. >>> 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 >> jenkinsci-dev+unsubscr...@googlegroups.com. >> 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 jenkinsci-dev+unsubscr...@googlegroups.com. > 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAA0qCNyVi1MVXXCzdSuDrOFsq0Kz%3D26KjFN7%2BePziArjRAF2_g%40mail.gmail.com.
