JEP |
9 |
|---|---|
Title |
How BDFL Delegates |
Sponsor |
|
Status |
Draft 💬 |
Type |
Informational |
Created |
2018-08-06 |
"Delegate" is a mechanism baked into Jenkins Enhancement Process (JEP) where I delegate my responsibilities to oversee a JEP to another person. But JEP itself does not specify how a Delegate is chosen. That is up to the discretion of BDFL, aka me.
This note explains my current operating principle of how I choose a Delegate, what I expect out of them.
Different areas of the Jenkins community have different natural leaders. Some of them have formal designations, such as Daniel Beck as the security officer, or Carlos Sanchez as the leader of the cloud native SIG. Other leaders are more informal, such as Oleg Nenashev leading remoting, Mark Waite leading Git plugin, and so on.
Delegates are the extrapolation of this idea. The label "Delegate" is a badge that designates that the person is "in charge" of a specific area. It’s a way to give a bit more visibility to what’s often an implicit influence that such natural leaders already possess.
If the role of a Sponsor is to actually do the work, then I see the role of a Delegate is to facilitate that work; ensuring the consistency of the effort with other moving pieces and goals of the space in question, connecting people with other stakeholders, guiding Sponsors away from pitfalls, and empowering them so that they can achieve the goal they set out in JEP. It’s almost like a mentor.
The enumerated reponsibilities of BDFL, which a Delegate inherits in the context of a JEP, derive from there.
Delegates are important pillars of the Jenkins community, because they facilitate the work that happens. This community’s founding DNA is "lower barrier of entry", a belief that our collective success relies on empowering contributors to achieve their ideas. It is a belief that sharing ideas and hearing other people’s feedbacks will lead to better solutions. It is a belief that when we work together we can get "there" faster.
I expect Delegates to strive to embody these values themselves. I expect them to be able to use their power to drive a group of people toward a consensus, instead to override. The Delegate designation doesn’t mean you are free to achieve your mission, it means you enable others to achieve their mission in your space.
Delegates are not code reviewers. They are not an extra pair of eyeballs that provides safety and redundancy. In fact, often a Sponsor and a Delegate are the same person, for example when Daniel Beck is driving a new initiative in the security team. If this is the case for you and you need more eyeballs, as a Delegate I expect you to know where to get them, and when they provide opinions that are different from yours, I expect you to be able to resolve them.
Delegates are not JEP experts. What I require in Delegates is not the encycropedic knowledge of how the process works, but rather the ability to judge when you need that knowledge and who to talk to.
Whenever the work proposed in a JEP happens in an area of the community that already has existing formal/informal leader, they are my first consideration for the Delegate. I will provide some qualification of the person in question, how they have been acting as leaders.
When somebody opens up a whole new effort, in the area where there’s no existing effort, say Evergreen or Jenkins X, then 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 designate a Delegate 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 person as Delegate. Whenever this happens, I will update this JEP to record it.
Area |
Initial JEP |
BDFL Delegate |
Configuration as Code |
JEP-201 |
Ewelina Wilkosz |
Evergreen |
JEP-300 |
R. Tyler Croy |
Jenkins X |
JEP-400 |
James Strachan |
Cloud native SIG |
N/A (SIG charter) |
Carlos Sanchez |
Over the course of implementing JEP, I found myself in several conversations where Sponsors nominate people differently from who I would have. Resulting conversations led to the recognization that people have different pictures about what Delegates are. This JEP is a result of that, in order to clarify how this mechanism is currently utilized by BDFL.
The other motivation was to make Delegates understand the trust I am giving them.
Prior to JEP, people who led various efforts did so solely based on implicit influence. And long time contributors in the community just "knew" who those people were. But this scheme doesn’t work well as we scale up. People new to the community do not know who the leaders are. And given the size of the community, only few people know everything that’s going on. 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 person. 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.
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. Before embarking on 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 and that consensus. It’s difficult to commit to work on something big if the goal is constantly getting rehashed and people have no idea whether theeir work will be accepted in the end or not. The Delegate designation provides an air cover for these people, who doesn’t necessarily have the long experience working in the Jenkins community, to get their work done. This came up multiple times in my conversation with potential corporate contributors outside CloudBees.
Our community has some formal structures, such as officers, SIGs, teams, and so on. We want to avoid the situation where JEP designates one person as the ultimate authority while those structures designate another person in charge. This operating principle ensures that it doesn’t happen.
This JEP represents no new change; this has been the policy I’ve been using to select Delegates all along, see my original explanation of how I select Delegates that I provided when we launched JEP.
If a trust given to a Delegate is misused, I expect JEP sponsors and others to tell that to me, so that I can change the delegate, revise the approach, and so on.
I will judge the effectiveness of this operating principle by whether Sponsors feel empowered and productive. If you have thoughts and feedbacks, please send those to me.