I'm +1 on the sentiment. My main concern is with the potential for effort to be gated on documentation review. This essentially requires design review for all new features before development begins. Great in theory, but I worry in practice things may get held up while we try to work out details that are possibly better worked out from an actual implementation (of course there's nothing to stop you from just doing a spike to play with the concepts). My other concern is whether this may prove to be a barrier to development for new contributors?
Still, I'm +1, but let's evaluate after some amount of time to assess what the impact has been? On Mon, Oct 13, 2014 at 2:07 PM, Bill Farner <wfar...@apache.org> wrote: > Slight change of position - i think the documentation with the pitch should > reflect the end state. In other words, it should be suitable for > committing on master when the feature is ready; and not be a pitch itself. > This is slightly different from the doc linked above. > > -=Bill > > On Mon, Oct 13, 2014 at 1:49 PM, Bill Farner <wfar...@apache.org> wrote: > > > Maxim's 'External Update Coordination' thread [1] sets a precedent for > > pitching a feature via documentation before diving into code. I propose > we > > standardize on this practice for big and small features. This will take > > some trial-and-error to get right, but i think for small changes > requiring > > documentation, they are both committed at once. For large features, the > > documentation helps define the requirements and seed a discussion, and is > > committed once the feature can be used. > > > > Any +/-1s on this approach? > > > > > > [1] > > > http://mail-archives.apache.org/mod_mbox/incubator-aurora-dev/201410.mbox/%3CCAOTkfX7x2oipk4ZFysoS0uWZRizOnKJA3y15pvEW5K4YnUHw-A%40mail.gmail.com%3E > > > > > > -=Bill > > >
