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.
