> On 19. Sep 2017, at 19:12, R. Tyler Croy <ty...@monkeypox.org> 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/51192308-6CA5-4DD8-8389-B5EA88C39D10%40beckweb.net. For more options, visit https://groups.google.com/d/optout.
