cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Parashuram N (MS OPEN TECH)" <panar...@microsoft.com>
Subject RE: Discussions on vote threads
Date Mon, 20 Apr 2015 00:48:51 GMT
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: agrieve@google.com [mailto:agrieve@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.treggiari@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: agrieve@google.com [mailto:agrieve@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 <bowserj@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 <agrieve@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?
> > >
> >
>
Mime
View raw message