I'll tell you why I didn't raise my question until now. Sorry it was on the vote thread, but it was the first time that I was able to see the information that I needed to understand exactly (at least better) what was going to happen with whitelisting. Actually, the title of the message (that is was a vote thread) never made it to my forefront consciousness.
This is a process suggestion and I hope you take it in the spirit of trying to make the process better and the project releases better. Maybe *my* problem is exactly just that and no one else is having the same problem. I have a hard time figuring out to any level of detail what is being changed/added in any release. Sometimes there are written proposals that go into some level of detail. Then there are e-mail discussions and/or comments made to a document. But not often do I see the original proposal updated with final decisions before a release occurs. So how many people know what is actually happening in a release at more than the level that, e.g., whitelisting is changing and there are some new plugins. If I wrote the code I'd know. If I reviewed the code, I’d probably know. If I tried to piece together the likely changes by following all discussions and comments, I might know. I did not write or review the code and I try at keeping up with the discussions but it still leaves me with questions. Even after a release, I often find it difficult to find a description (spec or documentation) about exactly how something is supposed to work. So here is a rough suggestion about how I think things could improve. I'm just a downstream consumer and so I don't expect my opinions to carry much weight compared to you who have created and maintained Cordova over years. Imagine there was a complete spec to the visible functionality in Cordova, including plugins, CLI commands, configuration files, etc. Certainly a lot exists but I have found myself in the situation where I can find no documentation about some option or some 'corner case'. If you think the project already has this, great - step 1 is done. When a proposal is made to change the visible functionality, the differences to the existing spec are documented in a proposal spec and then reviewed by this mailing list. Discussions take place like they do today, but at some point the proposer decides the discussions have died down and then updates the proposal spec. Maybe there is some further discussion based upon the update or not. However, with the update(s) to the proposal spec everyone should be able to understand what is expected when the proposed functionality is released and should raise any issues or questions before vote time comes. With the release, the information in the proposal spec can be merged into the complete public spec. So that's my excuse regarding why my questions and issues are often "last minute". Other than of course, "my cat ate my e-mail!" Leo -----Original Message----- From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve Sent: Thursday, April 09, 2015 1:01 PM To: dev Subject: Re: Discussions on vote threads That's a good point. Perhaps we should update our template to say "minium or 48 hours, and at least 24 hours after the last non-vote comment" On Thu, Apr 9, 2015 at 3:58 PM, Joe Bowser <bows...@gmail.com> wrote: > There's nothing wrong with the practice except that a vote thread with > comments means that we probably shouldn't proceed and should discuss it > more. Too much discussion on vote thread means we don't have any sort of > consensus and should work that out first. > > On Thu, Apr 9, 2015, 12:52 PM Andrew Grieve <agri...@chromium.org> wrote: > > > Have become very common for us. Probably because the release VOTE is the > > thing that actually gets people motivated to take a good look. > > > > Thought it'd be good for us to discuss this practice. > > > > My thoughts: > > - I think it still makes sense to DISCUSS before starting a release > > - I think it's perfectly reasonable to go through several RCs as things > > come up during testing (RCs are easy) > > - I think it helps to have the blog post ready before a vote (I made this > > change to the platforms release process this time around) > > - I don't have any problem with VOTE threads that are full of discussion. > > What's the concern? > > >
