This is a ton of great feedback, thanks! Ewelina,
JEPs have a number of purposes, but they are definitely _not_ meant to stifle innovation. At minimum though, they are meant to provide a medium for building consensus on the design and implementation of major features/processes of the Jenkins (and related) project. Without JEP, contributors such as yourself, might do months of work only to have that work rejected or asked to be redesigned. From the other side, the Project might get random contributors who ride in and want to have drop in some massive features without having discussed and reviewed with the rest of the project. I think the main misunderstanding (due to lack of clarity in JEP-1) is the idea that a JEP must be "Accepted" in order for contributors to have confidence in the value and validity of their work. That is absolutely not the case. "Accepted" means that that Reviewer and Sponsor have looked at the JEP and agreed that _scoping and design_ are complete and have the consensus of the community, and that what remains is completing the (already well underway) implementation. "Accepted" is a description of the technical state of the proposed component/feature/process. "Accepted" is _not_ (and should not be viewed or used as) a "vote of confidence". Conversely, "Draft" is not a commentary on the likelihood that the JEP will eventually be "Accepted". That can only determined by the Sponsors and the Reviewers based on discussion and feedback on the mailing list or other forums. "Draft" is _not_ (and should not be viewed as) an indicator of any lack of confidence in a proposal. > 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? In short, yes, but as you might gather from my response above, that is not a bad thing. In the case of JEP-201, there has been no commentary it indicate that it lacks support, nor any doubt about the value of the work being done. I think that the lack of clarity about the meaning of "Accepted" extends to the reviewers, so JEP-201 was marked as "Accepted" before the design was sufficiently complete. But I also personally have no doubt that once the design is complete, JEP-201 will be "Accepted". > Maybe it wouldn't be the worst idea to organize a Jenkins Online Meetup around JEP concept? Yes, as noted above, I agree there is still misunderstanding about the JEP process. I wouldn't have though to have JOM on this, but maybe we should. It would be good to highlight that this process exists, talk about when and how to use it, and so on. It would probably have to wait until May (April is looking pretty full already). In the meanwhile, I still want to update JEP-1 to clarify Jesse, Thanks for responding. You devil's advocate helped me craft the above response. Also, do you feel we make it hard to file followup JEPs? Joseph, Carlos, I hope this response addresses your points. If not please say so, and I'll respond specifically. Thanks, -Liam On Fri, Mar 23, 2018 at 8:25 AM Jesse Glick <[email protected]> wrote: > On Fri, Mar 23, 2018 at 8:11 AM, Carlos Sanchez <[email protected]> wrote: > > "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. > > To play devil’s advocate (I do not have strong feelings about this), > we should just make it comfortable enough to file follow-up JEPs that > this is normal practice. A JEP should stay as a Draft until there is a > clearly working implementation released. Once Accepted, there should > no eyebrows raised by filing another (initially Draft) JEP like “2018 > refreshes to JEP-234 in light of mistakes made”. That can discuss any > compatibility issues that might affect early adopters of the original > version. > > -- > 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/CANfRfr0F9z4sXKfZOGU%3D2vtveBt%2BdqReBy%2B4o5tpcwmNTKYEOQ%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAA0qCNzNY4FZys4j7_bc07UmCkgaQf%3D0bMqn%2BDj_ogetDvTsGQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
