As a developer (cordova customer) who follows pretty much everything related to cordova development closely, I always look for a blog post or some form of changelog in the [VOTE]/[DISCUSS] thread, but rarely do I find one. That'll be a nice inclusion in the process for me, to say the least.
2015-04-19 21:48 GMT-03:00 Parashuram N (MS OPEN TECH) < panar...@microsoft.com>: > I think it is a great idea to have the blog post ready before we start the > DISCUSS. Should we try this out for a couple of releases in the future to > see if everyone gets and idea of what is being discussed, without having to > dig deep into the mailing lists. > > -----Original Message----- > From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew > Grieve > Sent: Thursday, April 9, 2015 5:04 PM > To: dev > Subject: Re: Discussions on vote threads > > Both good feedback Jesse & Leo! > > I'll update the email templates to state discussion should happen on the > DISCUSS thread. > > Leo - Maybe one baby step towards what you describe is having the blog > post ready in the DISCUSS before the VOTE happens? Might be able to do more > what you describe, but I think you (or someone else who fully groks it) > would need to try it out for a release and see how it goes. > > On Thu, Apr 9, 2015 at 5:05 PM, Treggiari, Leo <leo.treggi...@intel.com> > wrote: > > > 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? > > > > > > > > > > -- *Frederico Galvão* Diretor de Tecnologia PontoGet Inovação Web ( +55(62) 8131-5720 * www.pontoget.com.br <http://www.pontoget.com/>
