cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Treggiari, Leo" <>
Subject RE: Discussions on vote threads
Date Thu, 09 Apr 2015 21:05:15 GMT
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

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!"


-----Original Message-----
From: [] 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 <> 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 <> 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?
> >
View raw message