JEPs & BDFL ~ KK

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

JEPs & BDFL ~ KK

Jesse Glick-4
Shall

https://github.com/jenkinsci/jep/tree/master/jep/1#bdfl

be amended somehow, to not assume KK has time to get involved? For
example to cut out the BDFL layer between JEP editors/reviewers and
the governance meeting? Also

https://github.com/jenkinsci/jep/tree/master/jep/9#specification

As a practical matter,

https://github.com/jenkinsci/jep/tree/master/jep/1#jep-review

has never been followed very consistently in my experience;
implementations get merged and released following regular hosting
and/or code review processes, while the JEP is still officially a
“draft”, and the “accepted” and “final” phases are skipped or a
formality. Maybe it is time for a streamlined process.

--
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/CANfRfr3vvd_MN5YBd%2B4bz%3DDZXEYZ-Brz6TUggpUgkbc7SBnpLQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: JEPs & BDFL ~ KK

Kohsuke Kawaguchi
Administrator
A part of the original JEP was to design an aspirational collaboration process that we wanted to promote back then, and use the power of the process to achieve that. I feel like the situation and the priority has changed a little since then.

What I mentioned to a few people on various occasions is that IMHO our current priority should be more on enabling existing doers to make impactful changes more easily, less on empowering new contributors to lead significant changes on their own.

So from that perspective, tweaking JEP to reflect how things are working in practice is a great idea. That's what I assume you meant by "streamlined process."

(That said, what I hate the most is for people to spend lots of time discussing how the process should be tweaked. That to me is the most counter productive!)

My 2 cents.

On Thu, Jan 23, 2020 at 8:56 AM Jesse Glick <[hidden email]> wrote:
Shall

https://github.com/jenkinsci/jep/tree/master/jep/1#bdfl

be amended somehow, to not assume KK has time to get involved? For
example to cut out the BDFL layer between JEP editors/reviewers and
the governance meeting? Also

https://github.com/jenkinsci/jep/tree/master/jep/9#specification

As a practical matter,

https://github.com/jenkinsci/jep/tree/master/jep/1#jep-review

has never been followed very consistently in my experience;
implementations get merged and released following regular hosting
and/or code review processes, while the JEP is still officially a
“draft”, and the “accepted” and “final” phases are skipped or a
formality. Maybe it is time for a streamlined process.


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

Re: JEPs & BDFL ~ KK

Oleg Nenashev
RE: "JEP-1 has never been followed very consistently in my experience. implementations get merged and released following regular hosting and/or code review processes". Let's face the reality, the JEP process is rather dead than alive at the moment. It is quite heavy to be followed, and right now it does not achieve its main purpose - facilitate the community feedback, help JEP submitters to get their changes delivered, and to ensure that all changes are net-positive for the Jenkins project and beneficial for Jenkins users down the line. Current process is quite heavy, and delays in JEP stages (e.g. BDFL Delegate delegation requires a direct message to KK to happen) defeat the purpose of JEPs. We want to help contributions, not to block changes by raising extra barriers. Be sure that contributors already have enough obstacles which block them from contributing to the project.

What is my approach w.r.t. JEPs as a core maintainer?
  • Consensus in the developer mailing list is a priority for me: feasibility, community value, design. If there is such consensus and no major concerns, JEP is NOT needed at all
  • JEP is a way to document the discussion feedback and agreements: discovered issues, concerns. It includes the feasibility, architecture/implementation and, last but not least, the rollout plan
  • If there is consensus in the dev list && Reference implementations get enough reviews, I am happy to deliver changes which are formally in draft. We have some tools for it:
    • "@Restricted(Beta.class)" for API changes
    • Changelogs/documentation - features can be documented as experimental
    • // The tools do not address all cases, but
  • If there are conflicting/intersecting proposals (e.g. JEP-223 and JEP-224), use mailing lists and JEPs as a way to discuss the proposals and to agree on the next steps
I am in favor of updating the JEP process a bit so that it becomes easier for contributors to deliver changes. It would be also great if it gets the BDLF out of the hook there so that he can focus on more important subjects. 
  • Update the JEP process to be auxiliary addition to developer list discussions, not the main venue to discuss all major changes as it is documented now. JEP process is followed if there is no consensus OR there is major impact on users (breaking changes)
  • remove the "BDFL Layer" in the initial draft review. As Jesse said, the "BDFL layer between JEP editors/reviewers and the governance meeting" does not look to be efficient at the moment. With the Governance Board recovered, delegation of the "BDFL Delegate" role could be done by the board or by the governance meeting so that 
  • Change the terminology to reflect the current state, similar to what KK says about changing the priorities for the JEP process
    • Add an "Author" role to JEP. This role represents JEP submitter and ones who implement it (part of the current "Sponsor role")
    • Merhge the remaining parts of the "Sponsor" role and "BDFL Delegate" to have a new "Sponsor" role: "an experienced contributor who helps the proposal to happen: ensure there is enough feedback and that all comments'concerns are addressed"
    • // Such change would also address my concern that "Sponsor" and "BDFL delegate" are the same person in many cases, which defeats the purpose of peer reviews. With an experienced contributors, IMO it is perfectly fine to have them as Sponsors 
  • Modify JEP stages to focus on the feature delivery process instead of the document review
    • Draft - there is a consensus in the community that it worth prototyping, but the details are under discussion && the implementation is not finalized.
    • Preview - the JEP is available as an experimental feature (opt-in, protected by feature flags and/or Beta API)
    • Delivered - the majority of the JEP scope is delivered. Minor leftovers may stay around
 
Sorry if I spend too much time discussing it :)

BR, Oleg



On Friday, January 24, 2020 at 5:44:06 PM UTC+1, Kohsuke Kawaguchi wrote:
A part of the original JEP was to design an aspirational collaboration process that we wanted to promote back then, and use the power of the process to achieve that. I feel like the situation and the priority has changed a little since then.

What I mentioned to a few people on various occasions is that IMHO our current priority should be more on enabling existing doers to make impactful changes more easily, less on empowering new contributors to lead significant changes on their own.

So from that perspective, tweaking JEP to reflect how things are working in practice is a great idea. That's what I assume you meant by "streamlined process."

(That said, what I hate the most is for people to spend lots of time discussing how the process should be tweaked. That to me is the most counter productive!)

My 2 cents.

On Thu, Jan 23, 2020 at 8:56 AM Jesse Glick <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="fiqb03A2EgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jgl...@...> wrote:
Shall

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

be amended somehow, to not assume KK has time to get involved? For
example to cut out the BDFL layer between JEP editors/reviewers and
the governance meeting? Also

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

As a practical matter,

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

has never been followed very consistently in my experience;
implementations get merged and released following regular hosting
and/or code review processes, while the JEP is still officially a
“draft”, and the “accepted” and “final” phases are skipped or a
formality. Maybe it is time for a streamlined process.


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1ec4f2eb-1255-4244-b393-473a3e0be0f1%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: JEPs & BDFL ~ KK

Jesse Glick-4
On Sun, Jan 26, 2020 at 4:28 PM Oleg Nenashev <[hidden email]> wrote:
> [the JEP process] does not achieve its main purpose - facilitate the community feedback, help JEP submitters to get their changes delivered, and to ensure that all changes are net-positive for the Jenkins project and beneficial for Jenkins users down the line.
> …
> JEP process is followed if there is no consensus OR there is major impact on users (breaking changes)

I would draw the line very differently and say that the JEP _process_
is not so important as the JEP itself: it is a single clear document
explaining to future generations how a particular major design
decision in Jenkins was made and why, all with an easily remembered
handle “JEP-456”. There need not be any breaking changes involved or
lack of consensus. In fact if there is no consensus then there is no
point in having a numbered JEP at all: you should first work to refine
your idea with skeptics, or just defer it. (File a draft PR if you
want something to refer to.)

Echoing KK (I think!), JEP should be a tool which assists people who
are already comfortable working on Jenkins. Keep the “editor” role,
responsible for matters of form and administration; and merge
“sponsor”, “contributors”, “BDFL”, “BDFL delegate”, and “reviewer”
into a simple “author” who is responsible for submitting the JEP,
doing the implementation, and delivering it, or delegating pieces of
this as they see fit. The board would just be a last resort in case
someone is trying to push through an unpopular change, with or without
a JEP.

--
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/CANfRfr2WCdgfmTLh7FM2JKhBQ-FEJx3_Bha8vjMCbWVS%3DsFHxA%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: JEPs & BDFL ~ KK

Daniel Beck-2


On Mon, Jan 27, 2020 at 2:55 PM Jesse Glick <[hidden email]> wrote:

Echoing KK (I think!), JEP should be a tool which assists people who
are already comfortable working on Jenkins. Keep the “editor” role,
responsible for matters of form and administration; and merge
“sponsor”, “contributors”, “BDFL”, “BDFL delegate”, and “reviewer”
into a simple “author” who is responsible for submitting the JEP,
doing the implementation, and delivering it, or delegating pieces of
this as they see fit. The board would just be a last resort in case
someone is trying to push through an unpopular change, with or without
a JEP.

I remember it as a tool to help especially less experienced contributors (from a governance/community involvement POV) get larger scale changes in without them lingering in review forever or being rejected at the last step, wasting a lot of time.

I don't know how well it worked for that use case but we should work towards enabling such work rather than just make it a place where "the regular suspects" document their major changes.

--
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/CAMo7Pt%2BOh29_385K2KJponNQvAG2z7uEKa7JLw0Vkj9pAN0arA%40mail.gmail.com.