Oleg, I just thought of one more possible change. Instead of having proposed JEPs sit as PRs until they meet the bar for "Draft", we should add a "sandbox" folder with named subfolders. So instead of having one pre-draft folder "0000" we can have many. This would allow people to more easily collaborate on getting JEPs to Draft state. Alternatively, we could have a jep-sandbox fork that holds the JEP sandbox (keeping the jep repo cleaner). That repo would have a wiki-style editing policy with a very low bar for getting contributor status, letting people make changes without PRs.
-L. On Wed, May 5, 2021 at 11:30 AM Liam Newman <[email protected]> wrote: > 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/CAA0qCNw%2Bxhfwf6MaX4kb6BpUiQHisbeDLu-3Jj8AquG0kVxGgA%40mail.gmail.com.
