You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Noah Slater <ns...@apache.org> on 2013/06/20 15:21:29 UTC
[VOTE] Update by-laws to add section for non-technical decision
making (Was: Re: [RESULTS][SUMMARY][DISCUSS][VOTE] List CloudStack related
books on the website)
Devs,
I would like to call a vote on the following modification to our by-laws.
This is in response to the
Summary of changes:
* Addition of "3.4.2. Non-Technical Decisions" section. This specifies that
non-technical decisions can be made on any appropriate list (i.e. marketing@)
and also allows us to vote on them with lazy 2/3 majority.
* Changed "The vote must occur on a project development mailing list." to
"The vote must occur on the project development mailing list." in several
places. This makes it explicit that these decisions must be made on
the dev@list.
* Minor rewordings, typographical changes, corrections, section
renumbering, etc.
(I would separate out the minor changes for a separate change, but as we're
voting on each change to this file, I want to reduce voting churn.)
Per the by-laws, we're using a lazy majority for this vote. Please cast
your vote now. I will tally the results in 72 hours.
Diff we're voting on:
Index: bylaws.mdtext
===================================================================
--- bylaws.mdtext (revision 1494950)
+++ bylaws.mdtext (working copy)
@@ -203,9 +203,9 @@
3.4.1. Technical Decisions
Technical decisions should normally be made by the entire community
-using consensus gathering, and not through formal voting.
+using discussion-lead consensus-building, and not through formal voting.
-Technical decisions must be made on a project development mailing list.
+Technical decisions must be made on the project development mailing list.
During the consensus gathering process, technical decisions may be vetoed
by any
Committer with a valid reason.
@@ -213,30 +213,47 @@
If a formal vote is started for a technical decision, the vote will be
held as a
lazy consensus of active committers.
-Any user, contributor, committer or PMC member can initiate a technical
desicion
+Any user, contributor, committer or PMC member can initiate a technical
decision
making process.
-3.4.2. Release Plan
+3.4.2. Non-Technical Decisions
+Non-technical decisions should normally be made by the entire community
using
+discussion-lead consensus-building, and not through formal voting.
+
+Non-technical decisions can be made on whichever project mailing list is
most
+appropriate.
+
+Non-technical decisions cannot be vetoed, but if there is strong opposition
+a formal vote can be used to resolve the dispute.
+
+If a formal vote is started for a non-technical decision, the vote will be
held
+as a lazy 2/3 majority of active committers.
+
+Any user, contributor, committer or PMC member can initiate a non-technical
+decision making process.
+
+3.4.3. Release Plan
+
Defines the timetable and work items for a release. The plan also
nominates a
Release Manager.
A lazy majority of active committers is required for approval.
-Any active committer or PMC member may call a vote. The vote must occur on
a
+Any active committer or PMC member may call a vote. The vote must occur on
the
project development mailing list.
-3.4.3. Product Release
+3.4.4. Product Release
When a release of one of the project's products is ready, a vote is
required to
accept the release as an official release of the project.
Lazy Majority of active PMC members is required for approval.
-Any active committer or PMC member may call a vote. The vote must occur on
a
+Any active committer or PMC member may call a vote. The vote must occur on
the
project development mailing list.
-3.4.4. Adoption of New Codebase
+3.4.5. Adoption of New Codebase
When the codebase for an existing, released product is to be replaced with
an
alternative codebase. If such a vote fails to gain approval, the existing
code
@@ -246,10 +263,10 @@
Lazy 2/3 majority of active PMC members.
-Any active committer or PMC member may call a vote. The vote must occur on
a
+Any active committer or PMC member may call a vote. The vote must occur on
the
project development mailing list.
-3.4.5. New Committer
+3.4.6. New Committer
When a new committer is proposed for the project.
@@ -258,7 +275,7 @@
Any active PMC member may call a vote. The vote must occur on the PMC
private
mailing list.
-3.4.6. New PMC Member
+3.4.7. New PMC Member
When a committer is proposed for the PMC.
@@ -267,7 +284,7 @@
Any active PMC member may call a vote. The vote must occur on the PMC
private
mailing list.
-3.4.7. Committer Removal
+3.4.8. Committer Removal
When removal of commit privileges is sought. Note: Such actions will also
be
referred to the ASF board by the PMC chair
@@ -278,7 +295,7 @@
Any active PMC member may call a vote. The vote must occur on the PMC
private
mailing list.
-3.4.8. PMC Member Removal
+3.4.9. PMC Member Removal
When removal of a PMC member is sought. Note: Such actions will also be
referred
to the ASF board by the PMC chair.
@@ -288,13 +305,13 @@
Any active PMC member may call a vote. The vote must occur on the PMC
private
mailing list.
-3.4.9. Modifying Bylaws
+3.4.10. Modifying Bylaws
Modifying this document.
Lazy majority of active PMC members
-Any active committer or PMC member may call a vote. The vote must occur on
a
+Any active committer or PMC member may call a vote. The vote must occur on
the
project development mailing list.
3.5. Voting Timeframes
On 20 June 2013 13:14, Noah Slater <ns...@apache.org> wrote:
> Sebastian,
>
> Thanks for the wrap up. I am happy with the way we proceeded here. It was
> a good compromise.
>
> As for the process stuff: Apache — as a community — uses
> discussion-lead consensus-based decision-making. (And formal voting is just
> one manifestation of that.) This should permeate everything we do. Every
> list, in other words.
>
> So the question isn't "where can votes happen?" (answer: everywhere Apache
> people exist!) but "where must certain types of decision be made?"
>
> I think we've established through past discussions around event
> organising, etc, that any sort of decision-making process in relation to
> marketing, the website, events, and branding, can, and probably should,
> happen on marketing@. There is no need to CC dev@.
>
> Any general, project-level stuff can be handled on dev@. In fact, "when
> in doubt, do it on dev@" is a decent rule of thumb.
>
> Perhaps we have not documented that marketing@ list is a suitable forum
> for certain types of decision making. It would probably be a good idea to
> do so. (But not doing so in the short term does not make existing decisions
> invalid. There is plenty of evidence in the mailing list archives to
> demonstrate the PMC is happy with this.)
>
> As for the by-laws. I agree. I will post a patch in a few minutes.
>
>
>
> On 17 June 2013 21:05, Rohit Yadav <bh...@apache.org> wrote:
>
>> On Tue, Jun 18, 2013 at 12:30 AM, Chip Childers
>> <ch...@sungard.com>wrote:
>>
>> > Adding Rohit via his a.o address.
>> >
>>
>> Thanks, yes please refrain from using my old/new corporate email
>> addresses.
>>
>> I'll stick to my initial vote and would propose listing the books on the
>> wiki immediately.
>>
>> Cheers.
>>
>>
>>
>> > On Mon, Jun 17, 2013 at 02:52:31PM -0400, Sebastien Goasguen wrote:
>> > > Ilya, Rohit, Joe, Noah,
>> > >
>> > > I am re-sending this with you in CC to make sure you read it.
>> > >
>> > > Since there was little response the wiki link has been established
>> > already, but I would like to get feedback on explicitly modifying the
>> > bylaws to explain that marketing topics happen on the marketing list and
>> > that Lazy majority or Lazy 2/3 majority will be required.
>> > >
>> > > -sebastien
>> > >
>> > > On Jun 12, 2013, at 6:12 AM, Sebastien Goasguen <ru...@gmail.com>
>> > wrote:
>> > >
>> > > > Hi, (note only marketing@)
>> > > >
>> > > > Apologies for a belated wrap up of this important vote. Please reply
>> > in-line.
>> > > >
>> > > > [RESULTS]:
>> > > >
>> > > > +1 : 24 (Sebastien, Giles, Nguyen, Ryan, Kelly, Geoff, Roland, Alex,
>> > Nehal, Sapm4kev, Gaspare, Kelcey, José,OutbackDingo, Todd, Eric, David,
>> > Kimihiko, Radhika, Clayton, Chip, Chiradeep, Tariq, Mark)
>> > > >
>> > > >
>> > > > -0 : 2 (Noah, Joe also vote +0)
>> > > >
>> > > > -1: 2 (Rohit, Ilya)
>> > > >
>> > > > [SUMMARY]:
>> > > >
>> > > > Rohit would be +1 on listing in the wiki, Ilya would be +0 on
>> listing
>> > in the wiki.
>> > > > So it seems that we would have unanimous consensus for listing on
>> the
>> > wiki, even though there is a strong majority for the website.
>> > > >
>> > > > [DISCUSS]:
>> > > >
>> > > > I felt it was important to poll folks that are only on dev@ or
>> users@and the results show that some folks who have never voted, got
>> engaged in
>> > this VOTE. This is a very positive side effect despite the confusion
>> that I
>> > created by bcc all lists.
>> > > >
>> > > > Our bylaws [1] do not cover votes on non-technical matters, so while
>> > we have lazy majority on this vote it seems that this situation is not
>> > covered by the bylaws. Moreover section 3.1.1 of bylaws says that
>> decisions
>> > on the project happen on dev@, so it seems that votes even on
>> marketing@are not allowed (unsure about this).
>> > > >
>> > > > I propose the following:
>> > > >
>> > > > 1-To move forward without having to re-cast a vote, I propose to
>> list
>> > immediately the books on the Wiki, and inform Packt. I just created the
>> > page [2]
>> > > > 2- If people agree that we have a bylaw "loophole", we need to
>> modify
>> > the bylaws to allow votes on marketing@ and agree on using Lazy
>> majority
>> > or Lazy 2/3 majority.
>> > > >
>> > > > Once we agree, I will inform users@ and dev@ and invite folks who
>> > participated in this vote to join marketing@
>> > > >
>> > > > 3- We could then re-cast a vote to list on the website
>> > > >
>> > > > [1] http://cloudstack.apache.org/bylaws.html
>> > > > [2]
>> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Books
>> > > >
>> > > > Ps: fwiw, I think this is overly complicated but the only way
>> forward
>> > in the apache way.
>> > > >
>> > > > -Sebastien
>> > >
>> > >
>> >
>>
>
>
>
> --
> NS
>
--
NS
Re: [VOTE] Update by-laws to add section for non-technical decision
making (Was: Re: [RESULTS][SUMMARY][DISCUSS][VOTE] List CloudStack related
books on the website)
Posted by Noah Slater <ns...@apache.org>.
I don't consider a website change to be technical.
On 20 June 2013 15:14, Joe Brockmeier <jz...@zonker.net> wrote:
> On Thu, Jun 20, 2013, at 08:21 AM, Noah Slater wrote:
> > Devs,
> >
> > I would like to call a vote on the following modification to our by-laws.
> > This is in response to the
> >
> > Summary of changes:
> >
> > * Addition of "3.4.2. Non-Technical Decisions" section. This specifies
> > that
> > non-technical decisions can be made on any appropriate list (i.e.
> > marketing@)
>
> Erm. Does this mean that marketing can't make any technical decisions
> about the Web site, for instance?
>
> I think this needs to be better worded.
>
>
> Best,
>
> jzb
> --
> Joe Brockmeier
> jzb@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/
>
--
NS
Re: [VOTE] Update by-laws to add section for non-technical decision
making (Was: Re: [RESULTS][SUMMARY][DISCUSS][VOTE] List CloudStack related
books on the website)
Posted by Noah Slater <ns...@apache.org>.
Everyone is free to propose changes to the by-laws. If you want to make a
patch and call a vote on it, by all means, go ahead. :) That sot of stuff
is a good way to become a committer in the first place. ;)
On 24 July 2013 18:34, Mathias Mullins <ma...@citrix.com> wrote:
> I'm not a committer so I don't want really to take this one on the Bylaws
> side. :-)
>
> Matt
>
>
> On 7/24/13 1:19 PM, "Noah Slater" <ns...@apache.org> wrote:
>
> >Nope. Sorry. Feel free to run with it. If not, I can see about doing
> >another vote in the next few days.
> >
> >
> >On 24 July 2013 18:02, Mathias Mullins <ma...@citrix.com>
> wrote:
> >
> >> Noah,
> >>
> >> Did you ever review / report / re-vote this?
> >>
> >> Thanks,
> >> Matt
> >>
> >>
> >> On 6/25/13 11:17 AM, "Noah Slater" <ns...@apache.org> wrote:
> >>
> >> >Thanks for the feedback, Matt.
> >> >
> >> >Anyone else got any feedback on this? Might cut a new vote.
> >> >
> >> >
> >> >On 24 June 2013 05:12, Mathias Mullins <ma...@citrix.com>
> >> wrote:
> >> >
> >> >> Noah,
> >> >>
> >> >> I agree that there needs to be a delineation. Here's my option on
> >> >>wording
> >> >> describing what is non-technical:
> >> >>
> >> >> +3.4.2. Non-Technical Decisions
> >> >>
> >> >> +Non-technical decisions should normally be made by the entire
> >>community
> >> >> using
> >> >> +discussion-lead consensus-building, and not through formal voting.
> >> >> +
> >> >> +Non-technical decisions are defined as a decision that do not
> >>directly
> >> >> affect
> >> >> +the code in any branch of the project.
> >> >> +Including coding, testing, documentation or management of the code
> >> >>base.
> >> >> +
> >> >> +Non-technical decisions can be made on whichever project mailing
> >>list
> >> >>is
> >> >> most
> >> >> +appropriate.
> >> >> +
> >> >> +Non-technical decisions cannot be vetoed, but if there is strong
> >> >> opposition
> >> >> +a formal vote can be used to resolve the dispute.
> >> >> +
> >> >> +If a formal vote is started for a non-technical decision, the vote
> >> >>will be
> >> >> held
> >> >> +as a lazy 2/3 majority of active committers.
> >> >> +
> >> >> +Any user, contributor, committer or PMC member can initiate a
> >> >> non-technical
> >> >> +decision making process.
> >> >>
> >> >>
> >> >>
> >> >> Matt Mullins
> >> >> Cloud Platforms Implementation Engineer
> >> >> Worldwide Cloud Services Citrix System, Inc.
> >> >> +1 (407) 920-1107 Office/Cell Phone
> >> >> matt.mullins@citrix.com
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On 6/20/13 11:59 AM, "Noah Slater" <ns...@apache.org> wrote:
> >> >>
> >> >> >Less terse follow up... ;)
> >> >> >
> >> >> >Note that our current by-laws effectively state that any technical
> >> >> >decision
> >> >> >needs to happen on dev@. I am just clarifying the intent.
> >> >> >
> >> >> >Note also that we currently do not define what a "technical
> >>decision"
> >> >>is,
> >> >> >but it is my opinion that this is any decision which relates to the
> >> >> >CloudStack source code. (We might want to make it a little broader
> >>than
> >> >> >that. Open to suggestions.)
> >> >> >
> >> >> >Almost everything we do involves technology. Whether that is editing
> >> >>the
> >> >> >website, wiki, JIRA, mailing lists, etc. That doesn't mean that
> >>those
> >> >> >activities are "technical activities" or involve "technical
> >>decisions".
> >> >> >
> >> >> >Do you think our by-laws need a section clarifying technical vs.
> >> >> >non-technical? What should it say?
> >> >> >
> >> >> >
> >> >> >On 20 June 2013 15:14, Joe Brockmeier <jz...@zonker.net> wrote:
> >> >> >
> >> >> >> On Thu, Jun 20, 2013, at 08:21 AM, Noah Slater wrote:
> >> >> >> > Devs,
> >> >> >> >
> >> >> >> > I would like to call a vote on the following modification to our
> >> >> >>by-laws.
> >> >> >> > This is in response to the
> >> >> >> >
> >> >> >> > Summary of changes:
> >> >> >> >
> >> >> >> > * Addition of "3.4.2. Non-Technical Decisions" section. This
> >> >>specifies
> >> >> >> > that
> >> >> >> > non-technical decisions can be made on any appropriate list
> >>(i.e.
> >> >> >> > marketing@)
> >> >> >>
> >> >> >> Erm. Does this mean that marketing can't make any technical
> >>decisions
> >> >> >> about the Web site, for instance?
> >> >> >>
> >> >> >> I think this needs to be better worded.
> >> >> >>
> >> >> >>
> >> >> >> Best,
> >> >> >>
> >> >> >> jzb
> >> >> >> --
> >> >> >> Joe Brockmeier
> >> >> >> jzb@zonker.net
> >> >> >> Twitter: @jzb
> >> >> >> http://www.dissociatedpress.net/
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> >--
> >> >> >NS
> >> >>
> >> >>
> >> >
> >> >
> >> >--
> >> >NS
> >>
> >>
> >
> >
> >--
> >NS
>
>
--
NS
Re: [VOTE] Update by-laws to add section for non-technical decision
making (Was: Re: [RESULTS][SUMMARY][DISCUSS][VOTE] List CloudStack related
books on the website)
Posted by Mathias Mullins <ma...@citrix.com>.
I'm not a committer so I don't want really to take this one on the Bylaws
side. :-)
Matt
On 7/24/13 1:19 PM, "Noah Slater" <ns...@apache.org> wrote:
>Nope. Sorry. Feel free to run with it. If not, I can see about doing
>another vote in the next few days.
>
>
>On 24 July 2013 18:02, Mathias Mullins <ma...@citrix.com> wrote:
>
>> Noah,
>>
>> Did you ever review / report / re-vote this?
>>
>> Thanks,
>> Matt
>>
>>
>> On 6/25/13 11:17 AM, "Noah Slater" <ns...@apache.org> wrote:
>>
>> >Thanks for the feedback, Matt.
>> >
>> >Anyone else got any feedback on this? Might cut a new vote.
>> >
>> >
>> >On 24 June 2013 05:12, Mathias Mullins <ma...@citrix.com>
>> wrote:
>> >
>> >> Noah,
>> >>
>> >> I agree that there needs to be a delineation. Here's my option on
>> >>wording
>> >> describing what is non-technical:
>> >>
>> >> +3.4.2. Non-Technical Decisions
>> >>
>> >> +Non-technical decisions should normally be made by the entire
>>community
>> >> using
>> >> +discussion-lead consensus-building, and not through formal voting.
>> >> +
>> >> +Non-technical decisions are defined as a decision that do not
>>directly
>> >> affect
>> >> +the code in any branch of the project.
>> >> +Including coding, testing, documentation or management of the code
>> >>base.
>> >> +
>> >> +Non-technical decisions can be made on whichever project mailing
>>list
>> >>is
>> >> most
>> >> +appropriate.
>> >> +
>> >> +Non-technical decisions cannot be vetoed, but if there is strong
>> >> opposition
>> >> +a formal vote can be used to resolve the dispute.
>> >> +
>> >> +If a formal vote is started for a non-technical decision, the vote
>> >>will be
>> >> held
>> >> +as a lazy 2/3 majority of active committers.
>> >> +
>> >> +Any user, contributor, committer or PMC member can initiate a
>> >> non-technical
>> >> +decision making process.
>> >>
>> >>
>> >>
>> >> Matt Mullins
>> >> Cloud Platforms Implementation Engineer
>> >> Worldwide Cloud Services Citrix System, Inc.
>> >> +1 (407) 920-1107 Office/Cell Phone
>> >> matt.mullins@citrix.com
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On 6/20/13 11:59 AM, "Noah Slater" <ns...@apache.org> wrote:
>> >>
>> >> >Less terse follow up... ;)
>> >> >
>> >> >Note that our current by-laws effectively state that any technical
>> >> >decision
>> >> >needs to happen on dev@. I am just clarifying the intent.
>> >> >
>> >> >Note also that we currently do not define what a "technical
>>decision"
>> >>is,
>> >> >but it is my opinion that this is any decision which relates to the
>> >> >CloudStack source code. (We might want to make it a little broader
>>than
>> >> >that. Open to suggestions.)
>> >> >
>> >> >Almost everything we do involves technology. Whether that is editing
>> >>the
>> >> >website, wiki, JIRA, mailing lists, etc. That doesn't mean that
>>those
>> >> >activities are "technical activities" or involve "technical
>>decisions".
>> >> >
>> >> >Do you think our by-laws need a section clarifying technical vs.
>> >> >non-technical? What should it say?
>> >> >
>> >> >
>> >> >On 20 June 2013 15:14, Joe Brockmeier <jz...@zonker.net> wrote:
>> >> >
>> >> >> On Thu, Jun 20, 2013, at 08:21 AM, Noah Slater wrote:
>> >> >> > Devs,
>> >> >> >
>> >> >> > I would like to call a vote on the following modification to our
>> >> >>by-laws.
>> >> >> > This is in response to the
>> >> >> >
>> >> >> > Summary of changes:
>> >> >> >
>> >> >> > * Addition of "3.4.2. Non-Technical Decisions" section. This
>> >>specifies
>> >> >> > that
>> >> >> > non-technical decisions can be made on any appropriate list
>>(i.e.
>> >> >> > marketing@)
>> >> >>
>> >> >> Erm. Does this mean that marketing can't make any technical
>>decisions
>> >> >> about the Web site, for instance?
>> >> >>
>> >> >> I think this needs to be better worded.
>> >> >>
>> >> >>
>> >> >> Best,
>> >> >>
>> >> >> jzb
>> >> >> --
>> >> >> Joe Brockmeier
>> >> >> jzb@zonker.net
>> >> >> Twitter: @jzb
>> >> >> http://www.dissociatedpress.net/
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> >--
>> >> >NS
>> >>
>> >>
>> >
>> >
>> >--
>> >NS
>>
>>
>
>
>--
>NS
Re: [VOTE] Update by-laws to add section for non-technical decision
making (Was: Re: [RESULTS][SUMMARY][DISCUSS][VOTE] List CloudStack related
books on the website)
Posted by Noah Slater <ns...@apache.org>.
Nope. Sorry. Feel free to run with it. If not, I can see about doing
another vote in the next few days.
On 24 July 2013 18:02, Mathias Mullins <ma...@citrix.com> wrote:
> Noah,
>
> Did you ever review / report / re-vote this?
>
> Thanks,
> Matt
>
>
> On 6/25/13 11:17 AM, "Noah Slater" <ns...@apache.org> wrote:
>
> >Thanks for the feedback, Matt.
> >
> >Anyone else got any feedback on this? Might cut a new vote.
> >
> >
> >On 24 June 2013 05:12, Mathias Mullins <ma...@citrix.com>
> wrote:
> >
> >> Noah,
> >>
> >> I agree that there needs to be a delineation. Here's my option on
> >>wording
> >> describing what is non-technical:
> >>
> >> +3.4.2. Non-Technical Decisions
> >>
> >> +Non-technical decisions should normally be made by the entire community
> >> using
> >> +discussion-lead consensus-building, and not through formal voting.
> >> +
> >> +Non-technical decisions are defined as a decision that do not directly
> >> affect
> >> +the code in any branch of the project.
> >> +Including coding, testing, documentation or management of the code
> >>base.
> >> +
> >> +Non-technical decisions can be made on whichever project mailing list
> >>is
> >> most
> >> +appropriate.
> >> +
> >> +Non-technical decisions cannot be vetoed, but if there is strong
> >> opposition
> >> +a formal vote can be used to resolve the dispute.
> >> +
> >> +If a formal vote is started for a non-technical decision, the vote
> >>will be
> >> held
> >> +as a lazy 2/3 majority of active committers.
> >> +
> >> +Any user, contributor, committer or PMC member can initiate a
> >> non-technical
> >> +decision making process.
> >>
> >>
> >>
> >> Matt Mullins
> >> Cloud Platforms Implementation Engineer
> >> Worldwide Cloud Services Citrix System, Inc.
> >> +1 (407) 920-1107 Office/Cell Phone
> >> matt.mullins@citrix.com
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 6/20/13 11:59 AM, "Noah Slater" <ns...@apache.org> wrote:
> >>
> >> >Less terse follow up... ;)
> >> >
> >> >Note that our current by-laws effectively state that any technical
> >> >decision
> >> >needs to happen on dev@. I am just clarifying the intent.
> >> >
> >> >Note also that we currently do not define what a "technical decision"
> >>is,
> >> >but it is my opinion that this is any decision which relates to the
> >> >CloudStack source code. (We might want to make it a little broader than
> >> >that. Open to suggestions.)
> >> >
> >> >Almost everything we do involves technology. Whether that is editing
> >>the
> >> >website, wiki, JIRA, mailing lists, etc. That doesn't mean that those
> >> >activities are "technical activities" or involve "technical decisions".
> >> >
> >> >Do you think our by-laws need a section clarifying technical vs.
> >> >non-technical? What should it say?
> >> >
> >> >
> >> >On 20 June 2013 15:14, Joe Brockmeier <jz...@zonker.net> wrote:
> >> >
> >> >> On Thu, Jun 20, 2013, at 08:21 AM, Noah Slater wrote:
> >> >> > Devs,
> >> >> >
> >> >> > I would like to call a vote on the following modification to our
> >> >>by-laws.
> >> >> > This is in response to the
> >> >> >
> >> >> > Summary of changes:
> >> >> >
> >> >> > * Addition of "3.4.2. Non-Technical Decisions" section. This
> >>specifies
> >> >> > that
> >> >> > non-technical decisions can be made on any appropriate list (i.e.
> >> >> > marketing@)
> >> >>
> >> >> Erm. Does this mean that marketing can't make any technical decisions
> >> >> about the Web site, for instance?
> >> >>
> >> >> I think this needs to be better worded.
> >> >>
> >> >>
> >> >> Best,
> >> >>
> >> >> jzb
> >> >> --
> >> >> Joe Brockmeier
> >> >> jzb@zonker.net
> >> >> Twitter: @jzb
> >> >> http://www.dissociatedpress.net/
> >> >>
> >> >
> >> >
> >> >
> >> >--
> >> >NS
> >>
> >>
> >
> >
> >--
> >NS
>
>
--
NS
Re: [VOTE] Update by-laws to add section for non-technical decision
making (Was: Re: [RESULTS][SUMMARY][DISCUSS][VOTE] List CloudStack related
books on the website)
Posted by Mathias Mullins <ma...@citrix.com>.
Noah,
Did you ever review / report / re-vote this?
Thanks,
Matt
On 6/25/13 11:17 AM, "Noah Slater" <ns...@apache.org> wrote:
>Thanks for the feedback, Matt.
>
>Anyone else got any feedback on this? Might cut a new vote.
>
>
>On 24 June 2013 05:12, Mathias Mullins <ma...@citrix.com> wrote:
>
>> Noah,
>>
>> I agree that there needs to be a delineation. Here's my option on
>>wording
>> describing what is non-technical:
>>
>> +3.4.2. Non-Technical Decisions
>>
>> +Non-technical decisions should normally be made by the entire community
>> using
>> +discussion-lead consensus-building, and not through formal voting.
>> +
>> +Non-technical decisions are defined as a decision that do not directly
>> affect
>> +the code in any branch of the project.
>> +Including coding, testing, documentation or management of the code
>>base.
>> +
>> +Non-technical decisions can be made on whichever project mailing list
>>is
>> most
>> +appropriate.
>> +
>> +Non-technical decisions cannot be vetoed, but if there is strong
>> opposition
>> +a formal vote can be used to resolve the dispute.
>> +
>> +If a formal vote is started for a non-technical decision, the vote
>>will be
>> held
>> +as a lazy 2/3 majority of active committers.
>> +
>> +Any user, contributor, committer or PMC member can initiate a
>> non-technical
>> +decision making process.
>>
>>
>>
>> Matt Mullins
>> Cloud Platforms Implementation Engineer
>> Worldwide Cloud Services Citrix System, Inc.
>> +1 (407) 920-1107 Office/Cell Phone
>> matt.mullins@citrix.com
>>
>>
>>
>>
>>
>>
>> On 6/20/13 11:59 AM, "Noah Slater" <ns...@apache.org> wrote:
>>
>> >Less terse follow up... ;)
>> >
>> >Note that our current by-laws effectively state that any technical
>> >decision
>> >needs to happen on dev@. I am just clarifying the intent.
>> >
>> >Note also that we currently do not define what a "technical decision"
>>is,
>> >but it is my opinion that this is any decision which relates to the
>> >CloudStack source code. (We might want to make it a little broader than
>> >that. Open to suggestions.)
>> >
>> >Almost everything we do involves technology. Whether that is editing
>>the
>> >website, wiki, JIRA, mailing lists, etc. That doesn't mean that those
>> >activities are "technical activities" or involve "technical decisions".
>> >
>> >Do you think our by-laws need a section clarifying technical vs.
>> >non-technical? What should it say?
>> >
>> >
>> >On 20 June 2013 15:14, Joe Brockmeier <jz...@zonker.net> wrote:
>> >
>> >> On Thu, Jun 20, 2013, at 08:21 AM, Noah Slater wrote:
>> >> > Devs,
>> >> >
>> >> > I would like to call a vote on the following modification to our
>> >>by-laws.
>> >> > This is in response to the
>> >> >
>> >> > Summary of changes:
>> >> >
>> >> > * Addition of "3.4.2. Non-Technical Decisions" section. This
>>specifies
>> >> > that
>> >> > non-technical decisions can be made on any appropriate list (i.e.
>> >> > marketing@)
>> >>
>> >> Erm. Does this mean that marketing can't make any technical decisions
>> >> about the Web site, for instance?
>> >>
>> >> I think this needs to be better worded.
>> >>
>> >>
>> >> Best,
>> >>
>> >> jzb
>> >> --
>> >> Joe Brockmeier
>> >> jzb@zonker.net
>> >> Twitter: @jzb
>> >> http://www.dissociatedpress.net/
>> >>
>> >
>> >
>> >
>> >--
>> >NS
>>
>>
>
>
>--
>NS
Re: [VOTE] Update by-laws to add section for non-technical decision
making (Was: Re: [RESULTS][SUMMARY][DISCUSS][VOTE] List CloudStack related
books on the website)
Posted by Noah Slater <ns...@apache.org>.
Thanks for the feedback, Matt.
Anyone else got any feedback on this? Might cut a new vote.
On 24 June 2013 05:12, Mathias Mullins <ma...@citrix.com> wrote:
> Noah,
>
> I agree that there needs to be a delineation. Here's my option on wording
> describing what is non-technical:
>
> +3.4.2. Non-Technical Decisions
>
> +Non-technical decisions should normally be made by the entire community
> using
> +discussion-lead consensus-building, and not through formal voting.
> +
> +Non-technical decisions are defined as a decision that do not directly
> affect
> +the code in any branch of the project.
> +Including coding, testing, documentation or management of the code base.
> +
> +Non-technical decisions can be made on whichever project mailing list is
> most
> +appropriate.
> +
> +Non-technical decisions cannot be vetoed, but if there is strong
> opposition
> +a formal vote can be used to resolve the dispute.
> +
> +If a formal vote is started for a non-technical decision, the vote will be
> held
> +as a lazy 2/3 majority of active committers.
> +
> +Any user, contributor, committer or PMC member can initiate a
> non-technical
> +decision making process.
>
>
>
> Matt Mullins
> Cloud Platforms Implementation Engineer
> Worldwide Cloud Services Citrix System, Inc.
> +1 (407) 920-1107 Office/Cell Phone
> matt.mullins@citrix.com
>
>
>
>
>
>
> On 6/20/13 11:59 AM, "Noah Slater" <ns...@apache.org> wrote:
>
> >Less terse follow up... ;)
> >
> >Note that our current by-laws effectively state that any technical
> >decision
> >needs to happen on dev@. I am just clarifying the intent.
> >
> >Note also that we currently do not define what a "technical decision" is,
> >but it is my opinion that this is any decision which relates to the
> >CloudStack source code. (We might want to make it a little broader than
> >that. Open to suggestions.)
> >
> >Almost everything we do involves technology. Whether that is editing the
> >website, wiki, JIRA, mailing lists, etc. That doesn't mean that those
> >activities are "technical activities" or involve "technical decisions".
> >
> >Do you think our by-laws need a section clarifying technical vs.
> >non-technical? What should it say?
> >
> >
> >On 20 June 2013 15:14, Joe Brockmeier <jz...@zonker.net> wrote:
> >
> >> On Thu, Jun 20, 2013, at 08:21 AM, Noah Slater wrote:
> >> > Devs,
> >> >
> >> > I would like to call a vote on the following modification to our
> >>by-laws.
> >> > This is in response to the
> >> >
> >> > Summary of changes:
> >> >
> >> > * Addition of "3.4.2. Non-Technical Decisions" section. This specifies
> >> > that
> >> > non-technical decisions can be made on any appropriate list (i.e.
> >> > marketing@)
> >>
> >> Erm. Does this mean that marketing can't make any technical decisions
> >> about the Web site, for instance?
> >>
> >> I think this needs to be better worded.
> >>
> >>
> >> Best,
> >>
> >> jzb
> >> --
> >> Joe Brockmeier
> >> jzb@zonker.net
> >> Twitter: @jzb
> >> http://www.dissociatedpress.net/
> >>
> >
> >
> >
> >--
> >NS
>
>
--
NS
Re: [VOTE] Update by-laws to add section for non-technical decision
making (Was: Re: [RESULTS][SUMMARY][DISCUSS][VOTE] List CloudStack related
books on the website)
Posted by Mathias Mullins <ma...@citrix.com>.
Noah,
I agree that there needs to be a delineation. Here's my option on wording
describing what is non-technical:
+3.4.2. Non-Technical Decisions
+Non-technical decisions should normally be made by the entire community
using
+discussion-lead consensus-building, and not through formal voting.
+
+Non-technical decisions are defined as a decision that do not directly
affect
+the code in any branch of the project.
+Including coding, testing, documentation or management of the code base.
+
+Non-technical decisions can be made on whichever project mailing list is
most
+appropriate.
+
+Non-technical decisions cannot be vetoed, but if there is strong
opposition
+a formal vote can be used to resolve the dispute.
+
+If a formal vote is started for a non-technical decision, the vote will be
held
+as a lazy 2/3 majority of active committers.
+
+Any user, contributor, committer or PMC member can initiate a
non-technical
+decision making process.
Matt Mullins
Cloud Platforms Implementation Engineer
Worldwide Cloud Services Citrix System, Inc.
+1 (407) 920-1107 Office/Cell Phone
matt.mullins@citrix.com
On 6/20/13 11:59 AM, "Noah Slater" <ns...@apache.org> wrote:
>Less terse follow up... ;)
>
>Note that our current by-laws effectively state that any technical
>decision
>needs to happen on dev@. I am just clarifying the intent.
>
>Note also that we currently do not define what a "technical decision" is,
>but it is my opinion that this is any decision which relates to the
>CloudStack source code. (We might want to make it a little broader than
>that. Open to suggestions.)
>
>Almost everything we do involves technology. Whether that is editing the
>website, wiki, JIRA, mailing lists, etc. That doesn't mean that those
>activities are "technical activities" or involve "technical decisions".
>
>Do you think our by-laws need a section clarifying technical vs.
>non-technical? What should it say?
>
>
>On 20 June 2013 15:14, Joe Brockmeier <jz...@zonker.net> wrote:
>
>> On Thu, Jun 20, 2013, at 08:21 AM, Noah Slater wrote:
>> > Devs,
>> >
>> > I would like to call a vote on the following modification to our
>>by-laws.
>> > This is in response to the
>> >
>> > Summary of changes:
>> >
>> > * Addition of "3.4.2. Non-Technical Decisions" section. This specifies
>> > that
>> > non-technical decisions can be made on any appropriate list (i.e.
>> > marketing@)
>>
>> Erm. Does this mean that marketing can't make any technical decisions
>> about the Web site, for instance?
>>
>> I think this needs to be better worded.
>>
>>
>> Best,
>>
>> jzb
>> --
>> Joe Brockmeier
>> jzb@zonker.net
>> Twitter: @jzb
>> http://www.dissociatedpress.net/
>>
>
>
>
>--
>NS
Re: [VOTE] Update by-laws to add section for non-technical decision
making (Was: Re: [RESULTS][SUMMARY][DISCUSS][VOTE] List CloudStack related
books on the website)
Posted by Noah Slater <ns...@apache.org>.
Less terse follow up... ;)
Note that our current by-laws effectively state that any technical decision
needs to happen on dev@. I am just clarifying the intent.
Note also that we currently do not define what a "technical decision" is,
but it is my opinion that this is any decision which relates to the
CloudStack source code. (We might want to make it a little broader than
that. Open to suggestions.)
Almost everything we do involves technology. Whether that is editing the
website, wiki, JIRA, mailing lists, etc. That doesn't mean that those
activities are "technical activities" or involve "technical decisions".
Do you think our by-laws need a section clarifying technical vs.
non-technical? What should it say?
On 20 June 2013 15:14, Joe Brockmeier <jz...@zonker.net> wrote:
> On Thu, Jun 20, 2013, at 08:21 AM, Noah Slater wrote:
> > Devs,
> >
> > I would like to call a vote on the following modification to our by-laws.
> > This is in response to the
> >
> > Summary of changes:
> >
> > * Addition of "3.4.2. Non-Technical Decisions" section. This specifies
> > that
> > non-technical decisions can be made on any appropriate list (i.e.
> > marketing@)
>
> Erm. Does this mean that marketing can't make any technical decisions
> about the Web site, for instance?
>
> I think this needs to be better worded.
>
>
> Best,
>
> jzb
> --
> Joe Brockmeier
> jzb@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/
>
--
NS
Re: [VOTE] Update by-laws to add section for non-technical decision
making (Was: Re: [RESULTS][SUMMARY][DISCUSS][VOTE] List CloudStack
related books on the website)
Posted by Joe Brockmeier <jz...@zonker.net>.
On Thu, Jun 20, 2013, at 08:21 AM, Noah Slater wrote:
> Devs,
>
> I would like to call a vote on the following modification to our by-laws.
> This is in response to the
>
> Summary of changes:
>
> * Addition of "3.4.2. Non-Technical Decisions" section. This specifies
> that
> non-technical decisions can be made on any appropriate list (i.e.
> marketing@)
Erm. Does this mean that marketing can't make any technical decisions
about the Web site, for instance?
I think this needs to be better worded.
Best,
jzb
--
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/
Re: [VOTE] Update by-laws to add section for non-technical decision
making (Was: Re: [RESULTS][SUMMARY][DISCUSS][VOTE] List CloudStack related
books on the website)
Posted by Noah Slater <ns...@apache.org>.
Uh... [This is in response to the] quoted thread wherein Sebastian
highlights that we have nothing in our by-laws to tell us how to make
general non-technical decisions.
On 20 June 2013 14:21, Noah Slater <ns...@apache.org> wrote:
> Devs,
>
> I would like to call a vote on the following modification to our by-laws.
> This is in response to the
>
> Summary of changes:
>
> * Addition of "3.4.2. Non-Technical Decisions" section.
> This specifies that non-technical decisions can be made on any appropriate
> list (i.e. marketing@) and also allows us to vote on them with lazy 2/3
> majority.
> * Changed "The vote must occur on a project development mailing list." to
> "The vote must occur on the project development mailing list." in several
> places. This makes it explicit that these decisions must be made on the dev@list.
> * Minor rewordings, typographical changes, corrections, section
> renumbering, etc.
>
> (I would separate out the minor changes for a separate change, but as
> we're voting on each change to this file, I want to reduce voting churn.)
>
> Per the by-laws, we're using a lazy majority for this vote. Please cast
> your vote now. I will tally the results in 72 hours.
>
> Diff we're voting on:
>
> Index: bylaws.mdtext
> ===================================================================
> --- bylaws.mdtext (revision 1494950)
> +++ bylaws.mdtext (working copy)
> @@ -203,9 +203,9 @@
> 3.4.1. Technical Decisions
>
> Technical decisions should normally be made by the entire community
> -using consensus gathering, and not through formal voting.
> +using discussion-lead consensus-building, and not through formal voting.
>
> -Technical decisions must be made on a project development mailing list.
> +Technical decisions must be made on the project development mailing list.
>
> During the consensus gathering process, technical decisions may be vetoed
> by any
> Committer with a valid reason.
> @@ -213,30 +213,47 @@
> If a formal vote is started for a technical decision, the vote will be
> held as a
> lazy consensus of active committers.
>
> -Any user, contributor, committer or PMC member can initiate a technical
> desicion
> +Any user, contributor, committer or PMC member can initiate a technical
> decision
> making process.
>
> -3.4.2. Release Plan
> +3.4.2. Non-Technical Decisions
>
> +Non-technical decisions should normally be made by the entire community
> using
> +discussion-lead consensus-building, and not through formal voting.
> +
> +Non-technical decisions can be made on whichever project mailing list is
> most
> +appropriate.
> +
> +Non-technical decisions cannot be vetoed, but if there is strong
> opposition
> +a formal vote can be used to resolve the dispute.
> +
> +If a formal vote is started for a non-technical decision, the vote will
> be held
> +as a lazy 2/3 majority of active committers.
> +
> +Any user, contributor, committer or PMC member can initiate a
> non-technical
> +decision making process.
> +
> +3.4.3. Release Plan
> +
> Defines the timetable and work items for a release. The plan also
> nominates a
> Release Manager.
>
> A lazy majority of active committers is required for approval.
>
> -Any active committer or PMC member may call a vote. The vote must occur
> on a
> +Any active committer or PMC member may call a vote. The vote must occur
> on the
> project development mailing list.
>
> -3.4.3. Product Release
> +3.4.4. Product Release
>
> When a release of one of the project's products is ready, a vote is
> required to
> accept the release as an official release of the project.
>
> Lazy Majority of active PMC members is required for approval.
>
> -Any active committer or PMC member may call a vote. The vote must occur
> on a
> +Any active committer or PMC member may call a vote. The vote must occur
> on the
> project development mailing list.
>
> -3.4.4. Adoption of New Codebase
> +3.4.5. Adoption of New Codebase
>
> When the codebase for an existing, released product is to be replaced
> with an
> alternative codebase. If such a vote fails to gain approval, the existing
> code
> @@ -246,10 +263,10 @@
>
> Lazy 2/3 majority of active PMC members.
>
> -Any active committer or PMC member may call a vote. The vote must occur
> on a
> +Any active committer or PMC member may call a vote. The vote must occur
> on the
> project development mailing list.
>
> -3.4.5. New Committer
> +3.4.6. New Committer
>
> When a new committer is proposed for the project.
>
> @@ -258,7 +275,7 @@
> Any active PMC member may call a vote. The vote must occur on the PMC
> private
> mailing list.
>
> -3.4.6. New PMC Member
> +3.4.7. New PMC Member
>
> When a committer is proposed for the PMC.
>
> @@ -267,7 +284,7 @@
> Any active PMC member may call a vote. The vote must occur on the PMC
> private
> mailing list.
>
> -3.4.7. Committer Removal
> +3.4.8. Committer Removal
>
> When removal of commit privileges is sought. Note: Such actions will also
> be
> referred to the ASF board by the PMC chair
> @@ -278,7 +295,7 @@
> Any active PMC member may call a vote. The vote must occur on the PMC
> private
> mailing list.
>
> -3.4.8. PMC Member Removal
> +3.4.9. PMC Member Removal
>
> When removal of a PMC member is sought. Note: Such actions will also be
> referred
> to the ASF board by the PMC chair.
> @@ -288,13 +305,13 @@
> Any active PMC member may call a vote. The vote must occur on the PMC
> private
> mailing list.
>
> -3.4.9. Modifying Bylaws
> +3.4.10. Modifying Bylaws
>
> Modifying this document.
>
> Lazy majority of active PMC members
>
> -Any active committer or PMC member may call a vote. The vote must occur
> on a
> +Any active committer or PMC member may call a vote. The vote must occur
> on the
> project development mailing list.
>
> 3.5. Voting Timeframes
>
> On 20 June 2013 13:14, Noah Slater <ns...@apache.org> wrote:
>
>> Sebastian,
>>
>> Thanks for the wrap up. I am happy with the way we proceeded here. It was
>> a good compromise.
>>
>> As for the process stuff: Apache — as a community — uses
>> discussion-lead consensus-based decision-making. (And formal voting is just
>> one manifestation of that.) This should permeate everything we do. Every
>> list, in other words.
>>
>> So the question isn't "where can votes happen?" (answer: everywhere
>> Apache people exist!) but "where must certain types of decision be made?"
>>
>> I think we've established through past discussions around event
>> organising, etc, that any sort of decision-making process in relation to
>> marketing, the website, events, and branding, can, and probably should,
>> happen on marketing@. There is no need to CC dev@.
>>
>> Any general, project-level stuff can be handled on dev@. In fact, "when
>> in doubt, do it on dev@" is a decent rule of thumb.
>>
>> Perhaps we have not documented that marketing@ list is a suitable forum
>> for certain types of decision making. It would probably be a good idea to
>> do so. (But not doing so in the short term does not make existing decisions
>> invalid. There is plenty of evidence in the mailing list archives to
>> demonstrate the PMC is happy with this.)
>>
>> As for the by-laws. I agree. I will post a patch in a few minutes.
>>
>>
>>
>> On 17 June 2013 21:05, Rohit Yadav <bh...@apache.org> wrote:
>>
>>> On Tue, Jun 18, 2013 at 12:30 AM, Chip Childers
>>> <ch...@sungard.com>wrote:
>>>
>>> > Adding Rohit via his a.o address.
>>> >
>>>
>>> Thanks, yes please refrain from using my old/new corporate email
>>> addresses.
>>>
>>> I'll stick to my initial vote and would propose listing the books on the
>>> wiki immediately.
>>>
>>> Cheers.
>>>
>>>
>>>
>>> > On Mon, Jun 17, 2013 at 02:52:31PM -0400, Sebastien Goasguen wrote:
>>> > > Ilya, Rohit, Joe, Noah,
>>> > >
>>> > > I am re-sending this with you in CC to make sure you read it.
>>> > >
>>> > > Since there was little response the wiki link has been established
>>> > already, but I would like to get feedback on explicitly modifying the
>>> > bylaws to explain that marketing topics happen on the marketing list
>>> and
>>> > that Lazy majority or Lazy 2/3 majority will be required.
>>> > >
>>> > > -sebastien
>>> > >
>>> > > On Jun 12, 2013, at 6:12 AM, Sebastien Goasguen <ru...@gmail.com>
>>> > wrote:
>>> > >
>>> > > > Hi, (note only marketing@)
>>> > > >
>>> > > > Apologies for a belated wrap up of this important vote. Please
>>> reply
>>> > in-line.
>>> > > >
>>> > > > [RESULTS]:
>>> > > >
>>> > > > +1 : 24 (Sebastien, Giles, Nguyen, Ryan, Kelly, Geoff, Roland,
>>> Alex,
>>> > Nehal, Sapm4kev, Gaspare, Kelcey, José,OutbackDingo, Todd, Eric, David,
>>> > Kimihiko, Radhika, Clayton, Chip, Chiradeep, Tariq, Mark)
>>> > > >
>>> > > >
>>> > > > -0 : 2 (Noah, Joe also vote +0)
>>> > > >
>>> > > > -1: 2 (Rohit, Ilya)
>>> > > >
>>> > > > [SUMMARY]:
>>> > > >
>>> > > > Rohit would be +1 on listing in the wiki, Ilya would be +0 on
>>> listing
>>> > in the wiki.
>>> > > > So it seems that we would have unanimous consensus for listing on
>>> the
>>> > wiki, even though there is a strong majority for the website.
>>> > > >
>>> > > > [DISCUSS]:
>>> > > >
>>> > > > I felt it was important to poll folks that are only on dev@ or
>>> users@and the results show that some folks who have never voted, got
>>> engaged in
>>> > this VOTE. This is a very positive side effect despite the confusion
>>> that I
>>> > created by bcc all lists.
>>> > > >
>>> > > > Our bylaws [1] do not cover votes on non-technical matters, so
>>> while
>>> > we have lazy majority on this vote it seems that this situation is not
>>> > covered by the bylaws. Moreover section 3.1.1 of bylaws says that
>>> decisions
>>> > on the project happen on dev@, so it seems that votes even on
>>> marketing@are not allowed (unsure about this).
>>> > > >
>>> > > > I propose the following:
>>> > > >
>>> > > > 1-To move forward without having to re-cast a vote, I propose to
>>> list
>>> > immediately the books on the Wiki, and inform Packt. I just created the
>>> > page [2]
>>> > > > 2- If people agree that we have a bylaw "loophole", we need to
>>> modify
>>> > the bylaws to allow votes on marketing@ and agree on using Lazy
>>> majority
>>> > or Lazy 2/3 majority.
>>> > > >
>>> > > > Once we agree, I will inform users@ and dev@ and invite folks who
>>> > participated in this vote to join marketing@
>>> > > >
>>> > > > 3- We could then re-cast a vote to list on the website
>>> > > >
>>> > > > [1] http://cloudstack.apache.org/bylaws.html
>>> > > > [2]
>>> >
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Books
>>> > > >
>>> > > > Ps: fwiw, I think this is overly complicated but the only way
>>> forward
>>> > in the apache way.
>>> > > >
>>> > > > -Sebastien
>>> > >
>>> > >
>>> >
>>>
>>
>>
>>
>> --
>> NS
>>
>
>
>
> --
> NS
>
--
NS