I agree with Ewelina that *"all 'significant changes' to a JEP should be completed before it is Accepted"* looks like a requirement that may hinder innovation and experimentation on areas that are not clear from the start. I'd rather see a review process that can return the JEP to a draft state for a v2 where people can discuss the new changes
On Fri, Mar 23, 2018 at 7:53 AM, Ewelina Wilkosz <[email protected]> wrote: > I'm perfectly ok with starting a discussion about proposed change > > And in general I do not disagree with your proposal but I want to share my > doubts... when we started working on Jenkins Configuration as Code we had > an idea and then the idea has changed and I'm glad we put it all in one > document. Now when I see a requirement *"all 'significant changes' to a > JEP should be completed before it is Accepted"* it makes me worry that if > I end up working on next JEP, for another project, I will be very careful > and it will take ages to put it into "Accepted" (maybe it's not a problem). > And then, like with JCasC, we learn while we implement it, we discover > issues and things that we can't do the way we want to do. Do we have to > discover all of that before "Accepting" JEP? That is the first thought that > came into my mind. > > Maybe it is exactly what you want and I can fully understand that. It just > seems to me now that it is much more formal that I expected at the > beginning. > Maybe it's because it's a new process, or I just missed some information, > but then we should probably make sure that the information is there. We had > a short discussion about that on Gitter lately, about purpose of JEP and > which kind of things require JEP. You know that, a lot of people know, but > many don't. Maybe it wouldn't be the worst idea to organise a Jenkins > Online Meetup around JEP concept? > > > BR > Ewelina > > On Friday, March 23, 2018 at 12:47:52 AM UTC+1, Liam Newman wrote: >> >> We recently had a pull request with a number of significant changes filed >> against JEP-201 which has already been "Accepted" (see the JEP workflow >> outlined in JEP-1 <https://github.com/jenkinsci/jep/tree/master/jep/1> >> ). >> >> https://github.com/jenkinsci/jep/pull/59 >> >> This poses a problem because the JEP workflow doesn't contain guidance >> for making/tracking significant changes to JEPs. The intent of the process >> is for all major changes to land while the JEP is a "Draft". A JEP being >> "Accepted" means that a general consensus was reached regarding the design >> and scope of the component/area described by the JEP. Once a JEP is marked >> "Final", the workflow specifically states that changes should be made by >> filing a new JEP and marking the old one as "Superseded" when the new JEP >> is complete. >> >> I would like to add the following clarifications to JEP-1: >> >> 1. State specifically that all "significant changes" to a JEP should >> be completed before it is Accepted. This is pointed to in a number of >> places but may not be mentioned explicitly. >> 2. Define a "significant change" is any change that would modify the >> intent, scope, API, or overall behavior of the component. I will provide >> some examples. >> 3. If "significant changes" are proposed to an "Accepted" JEP, it is >> be the responsibility of the Sponsor to communicate those changes on the >> mailing list and make sure that people have sufficient opportunity to >> review and comment before merging those changes. A link to the thread >> should be included in the PR for the change and in the References section. >> 4. If there are strong objections to the proposed change, the >> Reviewer of the JEP may choose to return the JEP to a "Draft" state for >> continued discussion and re-review. >> >> (Items 1 and 2 are both clarifications. Item 3 is a reiteration of the >> existing responsibilities of the JEP Sponsor in light of 1 and 2. 4 is a >> reiteration of the existing of responsibilities and powers of the JEP >> Review in light of 1 and 2.) >> >> In the case of the above PR. it means that Ewelina would need to start a >> thread on the mailing list to discuss this change and give people time to >> review before we merge that change. >> >> What do people think of this? An feedback or suggestions? >> >> Thanks, >> Liam Newman >> JEP-1 Sponsor >> >> -- > 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/6b84a0b5-a23b-44cf-80b3-faac982448ac% > 40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-dev/6b84a0b5-a23b-44cf-80b3-faac982448ac%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALHFn6MDGa%3DXZ%2BiqsYSa5ETADkNTqohqYuFP%3Dm97xjX-kJCfew%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
