Hi all,
Sorry for being silent. I have blocked the original PR due to the BDFL
concern, so I wanted to let others to provide feedback.
The flip-down model works for me. It is pretty similar to what I proposed here
("Governance meeting mode")
<https://github.com/jenkinsci/jep/pull/1#discussion_r139899353>, so
definitely +1. It prevents the potential bottleneck and keeps JEP compliant
with the current Governance Meeting - driven process. From what I see, it
allows excluding the "BDFL" entity from the document for now. Generally I
am in favor of introducing the BDFL role, but I would do it in a separate
JEP.
Regarding the process, some minor comments...
- I would expect Delegates to be discussed in the mailing list before
the JEP submission, so it just needs approval at the governance meeting. I
hope it also resolves the timezone difference concern, because anybody will
be able to cast their votes in the mailing list in advance.
- Having multiple delegates would be useful in the case of shared areas
like Jenkins Core. In order to JEP to be accepted, all delegates should
either vote "yes" or abstain. If a delegate gets assigned, it seems
reasonable to grant a veto right (or not?).
BR, Oleg
суббота, 23 сентября 2017 г., 15:30:39 UTC+3 пользователь Daniel Beck
написал:
>
>
> > On 19. Sep 2017, at 19:12, R. Tyler Croy <ty...@monkeypox.org
> <javascript:>> wrote:
> >
> > While I had hoped we might be able to get some consensus in time for
> tomorrow's
> > project meeting
>
> There was none, it is (and always has been) scheduled for next week,
> September 27.
>
> Just general FYI to prevent confusion.
>
> > 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.
>
> This seems reasonable.
>
> I don't remember where I saw this, but a large (web browser perhaps?)
> project had their entire source code organized in nested directories that
> each optionally specify a (list of) 'component owners', and the rule that
> changed have to be signed off by the appropriate owners, preferring the
> more specific (towards deeply nested) owners over the less specific
> (towards root directory). I thought this was a neat idea back then, and see
> some similarities to this proposal.
>
> But AFAIUI, there's no strict requirement to make a specific contributor
> the delegate though, even if considered the maintainer, right? Can Oleg
> self-assign any remoting JEP, or would editors be expected to redirect
> mismatched requested delegates? Or how would that be handled? Also, how
> would Oleg propose large-scale remoting changes (it needs to be "other than
> themselves")? I expect the lack of widespread expertise here might be a
> major impediment in some subject areas.
>
> My apologies to Oleg for keeping bringing him/remoting up as example, but
> AFAICT remoting is one of few examples of a 'core' component with a single
> maintainer and no obvious alternative maintainer.
>
> The above questions notwithstanding, I think this approach is something we
> can get started with, and maybe adjust after a year or so if it doesn't
> work out for any reason. I don't expect it won't, but who knows. I like how
> in some areas we're not defining the details overly restrictively when we
> need to see how things work out.
>
>
--
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/0582c258-8ffb-4e59-a07f-c9027b0c44d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
