[PROPOSAL] Require an Issue for new features

[Leif Hedstrom <zw...@apache.org>]

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 

Re: [PROPOSAL] Require an Issue for new features

[Derek Dagit <da...@apache.org>]

+1

On Fri, May 10, 2019 at 6:53 AM Steven R. Feltner <sf...@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
>
>
>

Re: [PROPOSAL] Require an Issue for new features

["Steven R. Feltner" <sf...@godaddy.com>]

+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
    

Re: [PROPOSAL] Require an Issue for new features

[Bryan Call <bc...@apache.org>]

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 <zwoop@apache.org <ma...@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 
> 

Re: [PROPOSAL] Require an Issue for new features

[Bryan Call <bc...@apache.org>]

+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> 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