You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Andrew Grieve <ag...@chromium.org> on 2015/04/09 21:50:32 UTC
Discussions on vote threads
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?
Re: Discussions on vote threads
Posted by Jesse <pu...@gmail.com>.
I don't view discussion as a vote blocker, and I am against anything that
delays shipping. I also think adding time based on comments is treating the
symptom ( uninformed + under-engaged ) when the problem was really perhaps
that the discuss conversation didn't go far enough.
We should definitely try to do it in the discuss thread, but a comment or a
question in vote does NOT mean a -1 in my opinion.
I think one practice we could add would be to include text in the vote
thread that points to the discuss thread, and invites people to re-read and
comment there.
@purplecabbage
risingj.com
On Thu, Apr 9, 2015 at 1:00 PM, Andrew Grieve <ag...@chromium.org> wrote:
> 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 <bo...@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 <ag...@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?
> > >
> >
>
Re: Discussions on vote threads
Posted by Frederico Galvão <fr...@pontoget.com.br>.
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) <
panarasi@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: 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 <le...@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 <bo...@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 <ag...@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/>
RE: Discussions on vote threads
Posted by "Parashuram N (MS OPEN TECH)" <pa...@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: 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 <le...@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 <bo...@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 <ag...@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?
> > >
> >
>
Re: Discussions on vote threads
Posted by Andrew Grieve <ag...@chromium.org>.
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 <le...@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 <bo...@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 <ag...@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?
> > >
> >
>
RE: Discussions on vote threads
Posted by "Treggiari, Leo" <le...@intel.com>.
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 <bo...@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 <ag...@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?
> >
>
Re: Discussions on vote threads
Posted by Andrew Grieve <ag...@chromium.org>.
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 <bo...@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 <ag...@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?
> >
>
Re: Discussions on vote threads
Posted by Joe Bowser <bo...@gmail.com>.
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 <ag...@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?
>
Re: Discussions on vote threads
Posted by Shazron <sh...@gmail.com>.
The vote itself should only be a formality really -- all issues should
have been hashed out in the Discuss thread. I think it's just a matter
of people getting used to this.
Vote threads full of discussion defeats the purpose of it. 1 or 2
off-topic items are okay now, but it can get de-railed into a 20 item
thread easily. When you are there to vote, you're there to vote.
On Thu, Apr 9, 2015 at 12:50 PM, Andrew Grieve <ag...@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?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org