Request for feedback: Jenkins Enhancement Proposal (JEP)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Request for feedback: Jenkins Enhancement Proposal (JEP)

R. Tyler Croy
At the Jenkins World Contributor Summit a couple weeks ago, I shared some
thoughts I have been having on how we can continue to grow and improve Jenkins.
One of those thoughts centers around the fundamental challenge: how do we, as a
group, make large transformational changes to Jenkins (and still get along and
like each other during the process).

Python users may recognize this structure, which is how the Python community
has organized their work. PEP in the Python community has allowed Python to
make *massive* changes over the past 15 years to what Python is, without
killing each other (very important).


I would like to propose the following process of a "Jenkins Enhancement
Proposal":

    https://github.com/jenkinsci/jep/tree/jep-1/jep/1


The overarching rationale for this proposal can be found in the rationale
section: https://github.com/jenkinsci/jep/tree/jep-1/jep/1#rationale

I also created an example of an Informational JEP here:
https://github.com/jenkinsci/jep/pull/2


For discussion on this foundational JEP, I suggest using this mailing list
thread. To propose changes, or fix some verbiage, feel free to open a pull
request targeting that `jep-1` branch.


To agree to this change in process, I don't think a "BDFL" or "BDFL-Delegate"
approval itself (read the doc) is sufficient. I think we should try to reach
consensus on this thread, and assuming there's consensus, approve the proposal
during the next Governance Meeting (Sept 27th).


Feel free to ping me via email or IRC if you have questions which you do not
feel belong in the mailing list discussion.


Thank you in advance for spending the time to read JEP-1 :)


Cheers
- R. Tyler Croy

------------------------------------------------------
     Code: <https://github.com/rtyler>
  Chatter: <https://twitter.com/agentdero>
     xmpp: [hidden email]

  % 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/20170913193251.3fohpy76pt5lo55p%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

Oliver Gondža-2
I suspect this question might have been asked in the room but are we ok
with the name collisions with Java Enhancement Proposals? Which one we
are referring to should be straightforward from the context but when
this becomes more widespread and changes will be refereed to by their
IDs, google searches will be quite confusing especially given the fact
the areas are somewhat related. How about JIP? or JEEP :P

--
oliver

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/bc7139d8-e24e-da6c-f8c0-c3bcca36f5fa%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

Jesse Glick-4
On Wed, Sep 13, 2017 at 3:55 PM, Oliver Gondža <[hidden email]> wrote:
> I suspect this question might have been asked in the room but are we ok with
> the name collisions with Java Enhancement Proposals?

I had the same thought. JKEP-nnn?

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2-AC-T2ACYKYwh_7qHZzRqAZ-nK0G1JmUnJrjDXuDqSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

R. Tyler Croy
In reply to this post by Oliver Gondža-2
(replies inline)

On Wed, 13 Sep 2017, Oliver Gond??a wrote:

> I suspect this question might have been asked in the room but are we ok with
> the name collisions with Java Enhancement Proposals? Which one we are
> referring to should be straightforward from the context but when this
> becomes more widespread and changes will be refereed to by their IDs, google
> searches will be quite confusing especially given the fact the areas are
> somewhat related. How about JIP? or JEEP :P


If I recall correctly, Jesse did mention the Java Enhancement Proposals acronym
collision at the Contributor Summit.

Personally, I'm not bothered at all by it at since jenkins.io and
openjdk.java.net are pretty distinguishable. If the acronym is of extremely high
importance to somebody, I don't mind changing to something similarly short and
understandable. No yak-shaving on acronyms allowed though :P



Cheers
- R. Tyler Croy

------------------------------------------------------
     Code: <https://github.com/rtyler>
  Chatter: <https://twitter.com/agentdero>
     xmpp: [hidden email]

  % 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/20170913200637.p32pkmumum54a7wg%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

Jesse Glick-4
In reply to this post by R. Tyler Croy
On Wed, Sep 13, 2017 at 3:32 PM, R. Tyler Croy <[hidden email]> wrote:
> I think we should try to reach
> consensus on this thread

Sounds like a good idea to me! Structure seems pretty clear.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr32TJTKwgWmM5oegVZDGCOHnxV-9EoDaO%2B71jBh6zR5-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

Keith Zantow-2
... random suggestion: "JPI" Jenkins Proposal Initiative/Initiation.

On Wed, Sep 13, 2017 at 4:23 PM, Jesse Glick <[hidden email]> wrote:
On Wed, Sep 13, 2017 at 3:32 PM, R. Tyler Croy <[hidden email]> wrote:
> I think we should try to reach
> consensus on this thread

Sounds like a good idea to me! Structure seems pretty clear.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr32TJTKwgWmM5oegVZDGCOHnxV-9EoDaO%2B71jBh6zR5-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAJTHQaGTECfjPPq_kDt81YEUuWubTmyAqq7b1X%2B4YoGtMrGJDw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

Owen Mehegan-2
Having read and edited JEP-1, I am in favor of this idea as presented :)

On Wed, Sep 13, 2017 at 1:34 PM, Keith Zantow <[hidden email]> wrote:
... random suggestion: "JPI" Jenkins Proposal Initiative/Initiation.

On Wed, Sep 13, 2017 at 4:23 PM, Jesse Glick <[hidden email]> wrote:
On Wed, Sep 13, 2017 at 3:32 PM, R. Tyler Croy <[hidden email]> wrote:
> I think we should try to reach
> consensus on this thread

Sounds like a good idea to me! Structure seems pretty clear.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr32TJTKwgWmM5oegVZDGCOHnxV-9EoDaO%2B71jBh6zR5-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAJTHQaGTECfjPPq_kDt81YEUuWubTmyAqq7b1X%2B4YoGtMrGJDw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAHtcACFrme5PD-FV8iJ9%2B4yraZtAhuX6iX68%2BtZ9-OYvYbsxfg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

Liam Newman
In reply to this post by R. Tyler Croy
I think this is great idea. I agree with the proposed process.
 
I think the proposal document itself could use some tweaks, which I've suggested in PR (oops oh well). 


On Wednesday, September 13, 2017 at 12:33:04 PM UTC-7, R Tyler Croy wrote:
At the Jenkins World Contributor Summit a couple weeks ago, I shared some
thoughts I have been having on how we can continue to grow and improve Jenkins.
One of those thoughts centers around the fundamental challenge: how do we, as a
group, make large transformational changes to Jenkins (and still get along and
like each other during the process).

Python users may recognize this structure, which is how the Python community
has organized their work. PEP in the Python community has allowed Python to
make *massive* changes over the past 15 years to what Python is, without
killing each other (very important).


I would like to propose the following process of a "Jenkins Enhancement
Proposal":

    <a href="https://github.com/jenkinsci/jep/tree/jep-1/jep/1" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjep%2Ftree%2Fjep-1%2Fjep%2F1\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEgkhFZ8tiJh51QN6TJGj_OEvI_8A&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjep%2Ftree%2Fjep-1%2Fjep%2F1\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEgkhFZ8tiJh51QN6TJGj_OEvI_8A&#39;;return true;">https://github.com/jenkinsci/jep/tree/jep-1/jep/1


The overarching rationale for this proposal can be found in the rationale
section: <a href="https://github.com/jenkinsci/jep/tree/jep-1/jep/1#rationale" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjep%2Ftree%2Fjep-1%2Fjep%2F1%23rationale\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHqbLFJOdnt_FyMq6V_SOmqtWhBcg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjep%2Ftree%2Fjep-1%2Fjep%2F1%23rationale\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHqbLFJOdnt_FyMq6V_SOmqtWhBcg&#39;;return true;">https://github.com/jenkinsci/jep/tree/jep-1/jep/1#rationale

I also created an example of an Informational JEP here:
<a href="https://github.com/jenkinsci/jep/pull/2" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjep%2Fpull%2F2\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFCYUHRgGpZN-SA7f5FEXybRYpq6Q&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjep%2Fpull%2F2\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFCYUHRgGpZN-SA7f5FEXybRYpq6Q&#39;;return true;">https://github.com/jenkinsci/jep/pull/2


For discussion on this foundational JEP, I suggest using this mailing list
thread. To propose changes, or fix some verbiage, feel free to open a pull
request targeting that `jep-1` branch.


To agree to this change in process, I don't think a "BDFL" or "BDFL-Delegate"
approval itself (read the doc) is sufficient. I think we should try to reach
consensus on this thread, and assuming there's consensus, approve the proposal
during the next Governance Meeting (Sept 27th).


Feel free to ping me via email or IRC if you have questions which you do not
feel belong in the mailing list discussion.


Thank you in advance for spending the time to read JEP-1 :)


Cheers
- R. Tyler Croy

------------------------------------------------------
     Code: <<a href="https://github.com/rtyler" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Frtyler\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFtsnCUZ085B8982iTQ2KFqz5gYhw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Frtyler\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFtsnCUZ085B8982iTQ2KFqz5gYhw&#39;;return true;">https://github.com/rtyler>
  Chatter: <<a href="https://twitter.com/agentdero" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Ftwitter.com%2Fagentdero\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEILlTAfpmlCsYIT_Phy_UKs4kUlw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Ftwitter.com%2Fagentdero\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEILlTAfpmlCsYIT_Phy_UKs4kUlw&#39;;return true;">https://twitter.com/agentdero>
     xmpp: <a href="javascript:" target="_blank" gdf-obfuscated-mailto="T9Nmhn-fAQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">rty...@...

  % gpg --keyserver <a href="http://keys.gnupg.net" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fkeys.gnupg.net\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGGvem0n8cSWWfyOfhzR-uVSpk4NQ&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fkeys.gnupg.net\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGGvem0n8cSWWfyOfhzR-uVSpk4NQ&#39;;return true;">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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/95e20056-7e89-4233-9a74-67522d0ea549%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

R. Tyler Croy
(replies inline)

On Wed, 13 Sep 2017, Liam Newman wrote:

> I think this is great idea. I agree with the proposed process.
>  
> I think the proposal document itself could use some tweaks, which I've
> suggested in PR (oops oh well).


No worries whatsoever! This is still fresh from the oven, so it's no problem
whatsoever to "cross the streams" which we get comfortable with a workflow
here.

I have addressed many of your comments in a pull request to the `jep-1` branch
here: https://github.com/jenkinsci/jep/pull/3


Of particular note for this group are some additions which I think Liam's 100%
in requesting, namely:

 * Consistently using Must/Should/May (https://github.com/jenkinsci/jep/pull/3/files#diff-43894e615b82e2536b1341c33ff49afeR116)
 * Structuring JEP-1 more closely with the sections JEP-1 outlines as important (https://github.com/jenkinsci/jep/pull/3/files#diff-43894e615b82e2536b1341c33ff49afeR565)



Thanks for helping!



- R. Tyler Croy

------------------------------------------------------
     Code: <https://github.com/rtyler>
  Chatter: <https://twitter.com/agentdero>
     xmpp: [hidden email]

  % 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/20170913214328.dctsetxh5mbfbumo%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

R. Tyler Croy
In reply to this post by R. Tyler Croy
(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: [hidden email]

  % 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/20170919171212.j3sjo4fawhisfieb%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

Robert Sandell-2
I didn't get the sense that the BDFL would be a bottle neck when you explained it to us at the contributor summit.
To me it seemed like the BDFL would only have to get involved if consensus between the author, editors and other reviewers can't be reached, or if he needs to put in a veto to stop something (in his mind) crazy from happening.

That said having Subject Matter Experts on hand to either serve as a "Deputy BDFL" for a specific area, or just someone that gets an explicit ping when a JEP affecting "their" area comes in might be good to have.

/B

2017-09-19 19:12 GMT+02:00 R. Tyler Croy <[hidden email]>:
(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: [hidden email]

  % 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/20170919171212.j3sjo4fawhisfieb%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.



--
Robert Sandell
Software Engineer
CloudBees Inc.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS0gCQcc3qAJJ%2Bimw2j4E-%3DqZVnwcrpP2AefFW000_Y0Kw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

Daniel Beck
In reply to this post by R. Tyler Croy

> On 19. Sep 2017, at 19:12, R. Tyler Croy <[hidden email]> 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 [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

Oleg Nenashev
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"), 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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="sb5M2FEkBQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">ty...@...> 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 [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

Daniel Beck

> On 27. Sep 2017, at 11:36, Oleg Nenashev <[hidden email]> wrote:
>
> 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.

TBH the group of potential delegates is fairly small. I expect we'll be able to self-select as appropriate, so I don't see the point in planning for the worst imaginable outcome. It'll just make for an unwieldy, bloated process. The best way to ensure that nothing ever gets done is to require project meeting involvement. On top of that, it excludes contributors from several continents. (And if people from those continents can 'vote from the mailing list', as you mention, why even tie it to the meeting?)

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/EB23042E-B108-462F-991C-845BF568A3E9%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

Oleg Nenashev
If there is a consensus in the mailing list, no strict need to involve the governance meeting from the technical PoV. The only purpose of the governance meeting here is to...
  • Act as a arbiter when there is no agreement in the mailing list
  • To legitimate the decisions, so that the proposal (accept JEP for review, assign delegates) becomes an official decision by the Jenkins project. It may prevent conflicts in the following cases:
    • JEP gets rejected, the submitter blames delegates due to a conflict of interest
    • JEP gets accepted, somebody chimes later and grumbles that people ignored his feedback and didn't select him as one of the delegates

So my point about the Governance Meeting is rather a protective one, it protects both community and delegates. In some cases it will be "process just for the process" for sure. Currently the Governance Meeting is IMHO the only legitimate institution in Jenkins (no "technical steering committee", board election fun), so that's why I propose to route the approval through the governance meeting.

BR, Oleg


2017-09-27 12:50 GMT+03:00 Daniel Beck <[hidden email]>:

> On 27. Sep 2017, at 11:36, Oleg Nenashev <[hidden email]> wrote:
>
> 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.

TBH the group of potential delegates is fairly small. I expect we'll be able to self-select as appropriate, so I don't see the point in planning for the worst imaginable outcome. It'll just make for an unwieldy, bloated process. The best way to ensure that nothing ever gets done is to require project meeting involvement. On top of that, it excludes contributors from several continents. (And if people from those continents can 'vote from the mailing list', as you mention, why even tie it to the meeting?)

--
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/spDAr8EJm3c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/EB23042E-B108-462F-991C-845BF568A3E9%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCWsvz25feJPc7kdZVjHxy7VhJoxLCqDg-f5cfyYD%2BQhw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

Daniel Beck

> On 27. Sep 2017, at 12:06, Oleg Nenashev <[hidden email]> wrote:
>
> If there is a consensus in the mailing list, no strict need to involve the governance meeting from the technical PoV. The only purpose of the governance meeting here is to...
> • Act as a arbiter when there is no agreement in the mailing list

Right, but we can just start a vote on the mailing list, too. Especially if half the people (or at least half the continents) would need to do that anyway.

> • To legitimate the decisions, so that the proposal (accept JEP for review, assign delegates) becomes an official decision by the Jenkins project. It may prevent conflicts in the following cases:
> • JEP gets rejected, the submitter blames delegates due to a conflict of interest

Should have chosen a different delegate then (remember, author chooses -- but I expect e.g. not choosing you for remoting will raise lots of eyebrows and will make people look closely).

> • JEP gets accepted, somebody chimes later and grumbles that people ignored his feedback and didn't select him as one of the delegates

If it's feedback by a single individual and everyone else is fine, that's consensus building in action. Consensus doesn't mean decisions need to be unanimous.

(Which is why I'd prefer to have rules specifying the security officer can veto for security reasons, and infra team lead can veto for infra reasons, but I trust that those concerns would be addressed in the process we're designing right now -- and if not, we'll adapt the process as needed.)

If the delegate actually ignores concerns brought by a majority of reviewers, I'd reconsider the eligibility of the delegate for future JEPs.

> So my point about the Governance Meeting is rather a protective one, it protects both community and delegates. In some cases it will be "process just for the process" for sure. Currently the Governance Meeting is IMHO the only legitimate institution in Jenkins (no "technical steering committee", board election fun), so that's why I propose to route the approval through the governance meeting.

If we're agreeing that this involvement of the project meeting would be a rare occurrence handling exceptional cases (if it's going to be 10% of JEPs we're still terrible), sure. But it still seems similar to adding rules for what should happen when we just start insulting or doxing each other. As in: if this happens, we have larger problems.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/C58BB914-52C2-4CFB-B7D3-64F575E582BB%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

R. Tyler Croy
In reply to this post by R. Tyler Croy

There has been a tremendous amount of productive discussion, with a lot of
helpful editing work by Liam. I think the process is ready for an approval in a
Governance meeting, so I'm going to put the proposal on the agenda for the Oct
11th meeting.


Proposal:

    https://github.com/jenkinsci/jep/tree/jep-1/jep/1


If you will be unable to join during the meeting, please respond to this thread
with your yay or nay.


Cheers

- R. Tyler Croy

------------------------------------------------------
     Code: <https://github.com/rtyler>
  Chatter: <https://twitter.com/agentdero>
     xmpp: [hidden email]

  % 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/20171005160110.csloavrsygdaqy3w%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

Daniel Beck

> On 5. Oct 2017, at 18:01, R. Tyler Croy <[hidden email]> wrote:
>
> There has been a tremendous amount of productive discussion, with a lot of
> helpful editing work by Liam. I think the process is ready for an approval in a
> Governance meeting, so I'm going to put the proposal on the agenda for the Oct
> 11th meeting.
>
>
> Proposal:
>
>    https://github.com/jenkinsci/jep/tree/jep-1/jep/1
>
>
> If you will be unable to join during the meeting, please respond to this thread
> with your yay or nay.

Tyler requested this topic be postponed to next meeting, as he's unable to make it to today's meeting.

So we all have two more weeks now to think about this proposal and provide feedback ;-)

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8C63BE5D-75AF-4FF6-B38D-F707AD1AFFF4%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

Jesse Glick-4
As an aside, it just occurred to me that JENKINS-41745 is something
that I would have done as a JEP had that existed at the time. Having
the templates and structure in place would have made it easier to
write up the proposal

https://gist.github.com/jglick/9721427da892a9b2f75dc5bc09f8e6b3

and of course would have provided a nicer permalink. :-)

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2vTcdhJiCfzPdKhFtqHBd6vXj%3DZ-38b07bRANk%3Dj8deg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

Daniel Beck

> On 11. Oct 2017, at 21:03, Jesse Glick <[hidden email]> wrote:
>
> As an aside, it just occurred to me that JENKINS-41745 is something
> that I would have done as a JEP had that existed at the time. Having
> the templates and structure in place would have made it easier to
> write up the proposal
>
> https://gist.github.com/jglick/9721427da892a9b2f75dc5bc09f8e6b3
>
> and of course would have provided a nicer permalink. :-)

Good point. That reminds me that I wrote up somewhat detailed proposals for changes to project infrastructure over the last year or so (first the introduction fine-grained Maven upload permissions, and later cutting the wiki dependency out of plugin distributions).

While those were nonpublic since they discuss (at the time) easily exploitable properties of the infra and how that would be fixed, being able to have that in a standard format, and publish it afterwards as documentation, would have been useful. (And I expect I'll need to make those into informational JEPs in the future…)

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/DDBEA867-F086-43DC-AB64-9DC27F135D3B%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
12