I would also like to add that people should also send an email to the dev@ mailing list with [PROPOSAL] in the subject with a link over to the issue. I don’t know if people look at new issues coming in.
-Bryan > On May 10, 2019, at 11:33 AM, Bryan Call <bc...@apache.org> wrote: > > +1 - I definite agree with this as was about to push send on a email about > this before Leif informed he already did. :) > > -Bryan > > > >> On May 9, 2019, at 9:06 AM, Leif Hedstrom <zw...@apache.org >> <mailto:zw...@apache.org>> wrote: >> >> Hi, >> >> As fa Follow-up to previous emails, I’d like to propose that new features, >> and major code changes affecting large portions of code and behaviors, must >> be documented in an Issue *before* development begins. It doesn’t have to be >> a book, but should outline the changes and additions, to allow for a >> discussion to take place. Neither does it imply that the design is rigid; >> often times, things change in the design as the implementation is done. But >> when that happens, the Issue should be updated accordingly, of course. >> >> The issues should be used to discuss the changes, and be given sufficient >> time to allow feedback before development. In addition, it assures that we >> are not working on the same things, or things that are opposing each other. >> The issues do not replace documentation, but can definitely help writing >> documentation, as well as release notes. >> >> The issue should be assigned with an expected version Project Version. >> That’s the second half of this; I believe this will help us further the goal >> of making feature focused releases. Also, it allows the community to >> priotize things such that we don’t get bogged down reviewing and fixing code >> which is not important to an upcoming release. And of course, it helps >> understanding why upgrading to a particular version is important for your >> org and projects. >> >> And discuss. >> >> — Leif >
