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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6b84a0b5-a23b-44cf-80b3-faac982448ac%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
