+1 On Fri, May 10, 2019 at 6:53 AM Steven R. Feltner <sfelt...@godaddy.com> wrote:
> +1 - I like this idea a lot > > > On 5/9/19, 12:06 PM, "Leif Hedstrom" <zw...@apache.org> wrote: > > Notice: This email is from an external sender. > > > > 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 > > >
