There's been quiet a bit of discussion offline about this I've closed #18 as Kohsuke's objections to it make it a non-starter.
I've instead opened * https://github.com/jenkinsci/jep/pull/19 that restores BDFL delegates * https://github.com/bitwiseman/jep/pull/1 proposed amendment to #19 that adds Governance meeting oversight of BDFL. Comments welcome, PR's with proposed fixes preferred. On Friday, October 20, 2017 at 11:08:27 AM UTC-7, Kohsuke Kawaguchi wrote: > > I admit I kept my eyes off this ball for a while. Naturally, I'm surprised > at this change. > > My understanding was that this change is being considered as a reaction to > those two concerns: > > > 1. Kohsuke as the BDFL introduces a problematic bottleneck to the process > > (there are way more of us, than there are of him). > > > > 2. JEP-1 introduces a different way of decision making than has been > > traditionally followed with the Governance Meeting > > (https://jenkins.io/project/governance/#meeting) > > I prefer the original "BDFL + Delegate" model. I'd like to explain the > reasons, and why that model adequately address those concerns. This is > going to be a long post. > > > First, the bottleneck point. As Bobby said in this thread and was > discussed in the contributor summit, I understood my role in this process > to be more like British Queen or Japanese Emperor, in the sense that I'm > expected to designate Delegate in each area and let them lead those areas, > as opposed to Supreme Court Justice who preside over individual cases. That > is, the idea is to influence Delegates instead of influencing JEPs. In this > manner, I don't think BDFL will be a bottleneck. > > The obvious question then would be how I pick Delegate. I think most area > has natural leads that owns the spaces. For example, Daniel leads security > related things, Oleg leads remoting, Jesse leads Pipeline, and so on. Those > people currently have implicit influences, and we know who they are. I > intend to designate them as Delegate. I will discuss that designation > beforehand to eliminate any chance of surprises. > > This brings me to one of the reasons why I'm supporting JEP. Today, people > who lead various efforts do so solely based on implicit influence. But this > scheme doesn't work well as we scale up. I see the Delegate title as a way > to make those implicit influences more explicit, so that people who are not > spending as much time in the project or contributors from organizations can > easily identify them as the primary go-to guy. Put differently, I want the > Delegate title to help those people lead more effectively. The officer > title worked very well with this regard. I think of Delegate as technical > version of it. Obviously, we don't want Delegate to be dictators any more > than you want BDFL to be actual dictator.And that spirit is captured in > JEP. We expect Delegate to understand implicit influences of other people > in neighboring areas and bring them in as appropriate. > > One of the problems I have with the proposed self-nominated Reviewer > scheme is that it does not help with this regard. There's no explicit title > like "Delegate" to clarify the role of leads. Those leads still need to > rely solely on implicit influences. > > > Back to how to pick Delegate. When we start a new effort, in the area > where there's no existing effort, say Jenkins 2 or pluggable storage, I > expect the initial JEP to capture goals and high level requirements of that > effort. I will be the reviewer of that initial JEP, but as a part of that > JEP I expect the Delegate to be determined for that space. Oftentimes the > sponsor of that JEP should be the obvious choice as the Delegate as the > leader of the effort. Other times we may need to have more discussions > among the core developers to determine that person. Subsequent JEP in that > space, to the extent it stays within the charter of the initial JEP, should > be presided by that Delegate. > > This brings me to another reason why I'm supporting JEP. Organized > contributors (aka companies putting their people into the project, as > opposed to individuals participating on their own initiatives) need this > kind of marking the space in which they execute in. Before driving a > non-trivial effort, there needs to be discussion and consensus that the > project accepts the idea (e.g., "there should be Jenkins 2 whose goals are > this and that".) Once that idea is agreed upon, we need to respect the > authority of the group who's working on it. They can't work on anything non > trivial if there's some sense that the work will be accepted in the end. > And often, people who lead those efforts have limited visibility in the > project. This came up multiple times in my conversation with potential > corporate contributors outside CloudBees. > > One of the problems I have with the removal of Delegate is that we lose > the tool to help make this authority explicit. And likewise, we lose the > continuity of Delegate. I hope we will have a lot of different Sponsors > trying to drive changes in the same area, and we need Delegate ensures that > there's some consistency and continuity, which requires a stable Delegate. > > > As for the second concern of the decision making structure outside the > governance meeting, I think what I'm describing above is very much in line > with how we have been operating on technical matters. We never really used > the governance meeting as a venue for technical decision making, and that's > the way I think it should be. It obviously provides a great place for > synchronous communication to bring people to some consensus faster, like > new LTS base version, but only a specific subset of people who work on > Jenkins are there. > > One of my goals in JEP is to clarify the path of technical decision > making. The original proposal does this by symbolically rooting the chain > of authority to BDFL (like how Queen and Emperor symbolically empowers the > elected government.) The removal of BDFL + Delegate tries to root the chain > of authority to "consensus of core contributors", but that fails to achieve > this goal because "core contributors" is not a group with clear boundary, > and we don't know how far "consensus" needs to be reached. > > > So there it is. I argue we should accept #12 > <https://github.com/jenkinsci/jep/pull/12> without #18 > <https://github.com/jenkinsci/jep/pull/18>. > > On Wed, Oct 18, 2017 at 4:45 PM Liam Newman <bitwi...@gmail.com > <javascript:>> wrote: > >> In the latest change, I've proposed removing the BDFL role. >> https://github.com/jenkinsci/jep/pull/18 to see the changes. >> >> (Note: in a previous PR I replaced the BDFL-delegate role with a >> "Reviewer" role and had expanded the description of BDFL.) >> >> I got it this far, but I'm out of bandwidth to make further changes this >> week. >> Oleg had some valid questions, and said he'd try to submit a PR >> addressing them. >> If anyone else wants to pick up a little of the load here, that'd be >> great - comments welcome, PRs preferred. >> >> Thanks, >> Liam Newman >> >> >> >> >> >> On Tuesday, September 19, 2017 at 10:12:29 AM UTC-7, R Tyler Croy wrote: >> >>> (replies inline) >>> >>> On Wed, 13 Sep 2017, R. Tyler Croy wrote: >>> >>> > https://github.com/jenkinsci/jep/tree/jep-1/jep/1 >>> >>> >>> Since I'm sure not everybody has been following along with some of the >>> pull >>> requests and changes while we've been hammering out JEP-1, I would like >>> to >>> provide a little bit of an update and solicit some help. This topic is >>> very >>> important, so please read this email! >>> >>> First, thanks to reviews from a number of folks including Oleg, Owen, >>> Daniel, >>> and others, we have been able to tighten the proposal up quite a bit. >>> Mostly >>> thanks to Liam's diligent slicing and dicing of text :) >>> >>> While I had hoped we might be able to get some consensus in time for >>> tomorrow's >>> project meeting, I don't think we are quite there yet. There has been >>> lots of >>> helpful feedback on the review and decision-making process >>> (BDFL/BDFL-delegate): >>> https://github.com/jenkinsci/jep/tree/jep-1/jep/1#review >>> >>> >>> To summarize the primary, and valid, criticisms if I may: >>> >>> 1. Kohsuke as the BDFL introduces a problematic bottleneck to the >>> process >>> (there are way more of us, than there are of him). >>> >>> 2. JEP-1 introduces a different way of decision making than has been >>> traditionally followed with the Governance Meeting >>> (https://jenkins.io/project/governance/#meeting) >>> >>> >>> I would like to guide the discussion towards addressing these. I also >>> want to >>> ensure our process is sensitive to contributors around the world, >>> especially >>> those in Australia and Asia who are typically asleep during the >>> scheduled >>> project meetings and rely on asynchronous mediums like email. >>> >>> If you have an example structure for technical decision-making from >>> another >>> project, which you think is applicable, please chime in! >>> >>> >>> Personally, what I'm thinking right now is to flip the Python model >>> upside >>> down: when the JEP Author creates a draft they (or a JEP Editor) list a >>> "Delegate" who would be somebody with good standing as the maintainer of >>> that >>> subject area, other than themselves. >>> >>> For example, if I were proposing a design on Remoting, Oleg would be the >>> obvious Delegate. If Andrew were proposing some design around Pipeline, >>> Jesse >>> would be a reasonable Delegate. Rather than expecting a BDFL to be >>> "plugged >>> into" each JEP, we self-select more (which I think we're all capable of >>> doing). >>> For the times when we might have conflcit, then we can use the >>> Governance >>> Meeting process to resolve who the appropriate Delegate for a proposal >>> may be. >>> To help new comers, including a list of "Suggested Delegates" in the JEP >>> repo >>> could also be helpful. >>> >>> I think that could avoid the problems with the current BDFL proposal, >>> while >>> reducing the need to run every JEP through the Governance Meeting >>> process, >>> where not all the stakeholders will necessarily be present. >>> >>> >>> >>> Of course, I'm open to more suggestions and discussion. Like I said at >>> the >>> beginning of the email, I think getting this right is important. >>> >>> >>> Cheers >>> - R. Tyler Croy >>> >>> ------------------------------------------------------ >>> Code: <https://github.com/rtyler> >>> Chatter: <https://twitter.com/agentdero> >>> >> xmpp: rty...@jabber.org >>> >> >>> % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F >>> ------------------------------------------------------ >>> >> -- >> 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 <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/78ac83c8-6290-41f9-98f9-7e977ec6004b%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jenkinsci-dev/78ac83c8-6290-41f9-98f9-7e977ec6004b%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > Kohsuke Kawaguchi > -- 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/93df1766-abb8-47a0-bbd5-2772961d062b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
