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
<https://github.com/jenkinsci/jep/tree/master/jep/223> and JEP-224
<https://github.com/jenkinsci/jep/tree/master/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 <[email protected]
> <javascript:>> 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/1ec4f2eb-1255-4244-b393-473a3e0be0f1%40googlegroups.com.
