| Message ID | 1452194242-10579-1-git-send-email-mike.holmes@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
On Thu, Jan 7, 2016 at 1:17 PM, Mike Holmes <mike.holmes@linaro.org> wrote: > The bylaws were only recorded as part of the website, move them to git > where they can be tracked. > > Signed-off-by: Mike Holmes <mike.holmes@linaro.org> > Reviewed-by: Bill Fischofer <bill.fischofer@linaro.org> > --- > doc/process-guide/Makefile.am | 10 ++-- > doc/process-guide/bylaws-guide.adoc | 104 > ++++++++++++++++++++++++++++++++++++ > 2 files changed, 110 insertions(+), 4 deletions(-) > create mode 100644 doc/process-guide/bylaws-guide.adoc > > diff --git a/doc/process-guide/Makefile.am b/doc/process-guide/Makefile.am > index 54e2c1d..1ac32da 100644 > --- a/doc/process-guide/Makefile.am > +++ b/doc/process-guide/Makefile.am > @@ -1,11 +1,13 @@ > -TARGET = $(top_srcdir)/doc/output/release-guide.html > +TARGET = $(top_srcdir)/doc/output/release-guide.html > $(top_srcdir)/doc/output/bylaws-guide.html > > -EXTRA_DIST = release-guide.adoc > +EXTRA_DIST = release-guide.adoc bylaws-guide.adoc > > all-local: $(TARGET) > > -$(TARGET): release-guide.adoc > - @mkdir -p $(top_srcdir)/doc/output > +$(top_srcdir)/doc/output/release-guide.html: release-guide.adoc > + asciidoc -b html5 -a icons -a toc2 -a max-width=55em > --out-file=$@ $< > + > +$(top_srcdir)/doc/output/bylaws-guide.html: bylaws-guide.adoc > asciidoc -b html5 -a icons -a toc2 -a max-width=55em > --out-file=$@ $< > > clean-local: > diff --git a/doc/process-guide/bylaws-guide.adoc > b/doc/process-guide/bylaws-guide.adoc > new file mode 100644 > index 0000000..91411da > --- /dev/null > +++ b/doc/process-guide/bylaws-guide.adoc > @@ -0,0 +1,104 @@ > +OpenDataPlane (ODP) Bylaws-Guide > +================================ > +:toc: > + > +:numbered!: > +[abstract] > +Abstract > +-------- > +This document is intended to guide a new application developer in > +understanding the bylaws > + > +The ODP project has established a set of by-laws defining the operational > +processes by which direction of ODP resources is determined and how the > product > +is managed. > + > +The by-laws define roles, stewardship/management, patch approvals, voting > +procedures, and reporting (Roadmap) requirements. > + > +Further details about ODP may be found at the http://opendataplane.org > [ODP] > +home page. > + > +:numbered: > + > +== Roles considered > +=== Users > +People that use the project and submit bugs and request new features to > the > +project. > + > +=== Contributors > +All of the volunteers who are contributing time, code, documentation, or > +resources to the project. A contributor that makes sustained, welcome > +contributions to the project may be invited to become a maintainer, > though the > +exact timing of such invitations depends on many factors. > + > +If a contributor wants to move the project in direction X or add feature > Y, and > +that requires a lot of rewrite in the existing code-base then: > + > +* explain that in an email to the mailing list. > +* send out RFCs (early and often) with example code, so the community (and > +maintainers) can see what you want and say if it fits or not. > + > +The above helps find and solve common problems among contributors. > + > +=== Maintainer(s) > +* The maintainer for a project have push rights to the main repo. Only one > +maintainer. The most trustworthy sub-maintainer shall step in and take > over the > +maintainer ship as required. > +* Sub-maintainer(s) one or many for the different modules in the project. > +* Sub-maintainers shall focus on ensuring that the current code base has > good > +quality and review new patches to maintain that good quality. > +* When Maintainers accept code, they have to deal with it until they die > or rip > +it out (so its important that they understand what the code does and why > they > +need it). The contributor shall convince the maintainer to take their > code (the > +maintainer should feel like he would be stupid to not accept the code…) > + > +=== Release Manager === > + > +* The RM shall publish a Release Plan on the roadmap. One week before the > +release the candidate list will be reviewed. > +* The RM is responsible for building consensus around the content of the > +Release. > + > +== Roadmap > +The roadmap shall state projected future releases and the expected > content. > + > +== Steering Committee (SC) > +* Maintaining the project’s shared resources, email lists and the > homepage. > +* Speaking on behalf of the project. > +* Resolving license disputes regarding products of the project. > +* Nominating new PMC members and committers. > +* Maintaining these bylaws and other guidelines of the project. > +* Planning the roadmap (shall state projected future releases and the > expected > +content). > + > +=== Patch approval > +Reviewed-by is only replied to the list after inspecting the code. If you > have > +review comments they should be constructive and not just saying “no”. > +Reviewed-by and Signed-off-by implies that you are co-responsible for any > bugs > +found in the code. > + > +If you don’t respond you are assumed to agree with the patch. > + > +== Voting == > +Voting is necessary if consensus not has been reached. Must have > established > +quorum. > + > +* “Yes”, “Agree”,"+1" the action should be performed. > +In general, this vote also indicates a willingness on the behalf of the > voter in > +“making it happen” > + > +* “Abstain” This vote indicates that the voter abstains. > +The voter has no interest or does not participate in the vote. > + > +* “No”, “Disagree” "-1" the action should not be performed. > +On issues where consensus is required, this vote counts as a veto. All > vetoes > +must contain an explanation of why the veto is appropriate. Vetoes with no > +explanation are void. It may also be appropriate for a -1 vote to include > an > +alternative course of action. > + > +== Adding new features == > + > +If person X adds a new feature (API group X) then he should/could be > asked to > +be the maintainer for that feature. Code (old or new) is likely to be > removed > +if it is unmaintained. > -- > 2.5.0 > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp >
bellow are small notes but it's better to clean up it now. Maxim. On 01/07/2016 22:17, Mike Holmes wrote: > The bylaws were only recorded as part of the website, move them to git > where they can be tracked. > > Signed-off-by: Mike Holmes <mike.holmes@linaro.org> > --- > doc/process-guide/Makefile.am | 10 ++-- > doc/process-guide/bylaws-guide.adoc | 104 ++++++++++++++++++++++++++++++++++++ > 2 files changed, 110 insertions(+), 4 deletions(-) > create mode 100644 doc/process-guide/bylaws-guide.adoc > > diff --git a/doc/process-guide/Makefile.am b/doc/process-guide/Makefile.am > index 54e2c1d..1ac32da 100644 > --- a/doc/process-guide/Makefile.am > +++ b/doc/process-guide/Makefile.am > @@ -1,11 +1,13 @@ > -TARGET = $(top_srcdir)/doc/output/release-guide.html > +TARGET = $(top_srcdir)/doc/output/release-guide.html $(top_srcdir)/doc/output/bylaws-guide.html please do it in 2 lines (better to see later diffs), and alphabetical order. > > -EXTRA_DIST = release-guide.adoc > +EXTRA_DIST = release-guide.adoc bylaws-guide.adoc please do it in 2 lines (better to see later diffs), and alphabetical order. > > all-local: $(TARGET) > > -$(TARGET): release-guide.adoc > - @mkdir -p $(top_srcdir)/doc/output > +$(top_srcdir)/doc/output/release-guide.html: release-guide.adoc > + asciidoc -b html5 -a icons -a toc2 -a max-width=55em --out-file=$@ $< > + > +$(top_srcdir)/doc/output/bylaws-guide.html: bylaws-guide.adoc > asciidoc -b html5 -a icons -a toc2 -a max-width=55em --out-file=$@ $< > > clean-local: > diff --git a/doc/process-guide/bylaws-guide.adoc b/doc/process-guide/bylaws-guide.adoc > new file mode 100644 > index 0000000..91411da > --- /dev/null > +++ b/doc/process-guide/bylaws-guide.adoc > @@ -0,0 +1,104 @@ > +OpenDataPlane (ODP) Bylaws-Guide > +================================ > +:toc: > + > +:numbered!: > +[abstract] > +Abstract > +-------- > +This document is intended to guide a new application developer in > +understanding the bylaws dot is missing. In some places you have "bylaws" but in other "by-laws". Dictionary says that hyphen has to be used. Please fix it everywhere in doc. > + > +The ODP project has established a set of by-laws defining the operational > +processes by which direction of ODP resources is determined and how the product > +is managed. > + > +The by-laws define roles, stewardship/management, patch approvals, voting > +procedures, and reporting (Roadmap) requirements. > + > +Further details about ODP may be found at the http://opendataplane.org[ODP] > +home page. > + > +:numbered: > + > +== Roles considered > +=== Users How about name it: Users (ODP Applications developers). > +People that use the project and submit bugs and request new features to the > +project. > + > +=== Contributors > +All of the volunteers who are contributing time, code, documentation, or > +resources to the project. A contributor that makes sustained, welcome > +contributions to the project may be invited to become a maintainer, though the > +exact timing of such invitations depends on many factors. > + > +If a contributor wants to move the project in direction X or add feature Y, and > +that requires a lot of rewrite in the existing code-base then: > + > +* explain that in an email to the mailing list. > +* send out RFCs (early and often) with example code, so the community (and > +maintainers) can see what you want and say if it fits or not. > + > +The above helps find and solve common problems among contributors. > + > +=== Maintainer(s) > +* The maintainer for a project have push rights to the main repo. Only one > +maintainer. The most trustworthy sub-maintainer shall step in and take over the > +maintainer ship as required. > +* Sub-maintainer(s) one or many for the different modules in the project. > +* Sub-maintainers shall focus on ensuring that the current code base has good > +quality and review new patches to maintain that good quality. > +* When Maintainers accept code, they have to deal with it until they die or rip > +it out (so its important that they understand what the code does and why they > +need it). The contributor shall convince the maintainer to take their code (the > +maintainer should feel like he would be stupid to not accept the code…) > + > +=== Release Manager === > + > +* The RM shall publish a Release Plan on the roadmap. One week before the > +release the candidate list will be reviewed. > +* The RM is responsible for building consensus around the content of the > +Release. > + > +== Roadmap > +The roadmap shall state projected future releases and the expected content. > + > +== Steering Committee (SC) > +* Maintaining the project’s shared resources, email lists and the homepage. Maybe maintain is not right word here. Technically work operating of that services maintained by Linaro IT team. SC probably defines requirements for project support services. > +* Speaking on behalf of the project. > +* Resolving license disputes regarding products of the project. > +* Nominating new PMC members and committers. > +* Maintaining these bylaws and other guidelines of the project. > +* Planning the roadmap (shall state projected future releases and the expected > +content). > + > +=== Patch approval > +Reviewed-by is only replied to the list after inspecting the code. If you have > +review comments they should be constructive and not just saying “no”. > +Reviewed-by and Signed-off-by implies that you are co-responsible for any bugs > +found in the code. > + > +If you don’t respond you are assumed to agree with the patch. > + > +== Voting == > +Voting is necessary if consensus not has been reached. Must have established > +quorum. > + > +* “Yes”, “Agree”,"+1" the action should be performed. > +In general, this vote also indicates a willingness on the behalf of the voter in > +“making it happen” > + > +* “Abstain” This vote indicates that the voter abstains. > +The voter has no interest or does not participate in the vote. > + > +* “No”, “Disagree” "-1" the action should not be performed. > +On issues where consensus is required, this vote counts as a veto. All vetoes > +must contain an explanation of why the veto is appropriate. Vetoes with no > +explanation are void. It may also be appropriate for a -1 vote to include an > +alternative course of action. > + > +== Adding new features == > + > +If person X adds a new feature (API group X) then he should/could be asked to > +be the maintainer for that feature. Code (old or new) is likely to be removed > +if it is unmaintained.
On 11 January 2016 at 14:31, Maxim Uvarov <maxim.uvarov@linaro.org> wrote: > bellow are small notes but it's better to clean up it now. > > Maxim. > > On 01/07/2016 22:17, Mike Holmes wrote: > >> The bylaws were only recorded as part of the website, move them to git >> where they can be tracked. >> >> Signed-off-by: Mike Holmes <mike.holmes@linaro.org> >> --- >> doc/process-guide/Makefile.am | 10 ++-- >> doc/process-guide/bylaws-guide.adoc | 104 >> ++++++++++++++++++++++++++++++++++++ >> 2 files changed, 110 insertions(+), 4 deletions(-) >> create mode 100644 doc/process-guide/bylaws-guide.adoc >> >> diff --git a/doc/process-guide/Makefile.am b/doc/process-guide/Makefile.am >> index 54e2c1d..1ac32da 100644 >> --- a/doc/process-guide/Makefile.am >> +++ b/doc/process-guide/Makefile.am >> @@ -1,11 +1,13 @@ >> -TARGET = $(top_srcdir)/doc/output/release-guide.html >> +TARGET = $(top_srcdir)/doc/output/release-guide.html >> $(top_srcdir)/doc/output/bylaws-guide.html >> > please do it in 2 lines (better to see later diffs), and alphabetical > order. Thanks > > -EXTRA_DIST = release-guide.adoc >> +EXTRA_DIST = release-guide.adoc bylaws-guide.adoc >> > please do it in 2 lines (better to see later diffs), and alphabetical > order. Thanks > > > all-local: $(TARGET) >> -$(TARGET): release-guide.adoc >> - @mkdir -p $(top_srcdir)/doc/output >> +$(top_srcdir)/doc/output/release-guide.html: release-guide.adoc >> + asciidoc -b html5 -a icons -a toc2 -a max-width=55em >> --out-file=$@ $< >> + >> +$(top_srcdir)/doc/output/bylaws-guide.html: bylaws-guide.adoc >> asciidoc -b html5 -a icons -a toc2 -a max-width=55em >> --out-file=$@ $< >> clean-local: >> diff --git a/doc/process-guide/bylaws-guide.adoc >> b/doc/process-guide/bylaws-guide.adoc >> new file mode 100644 >> index 0000000..91411da >> --- /dev/null >> +++ b/doc/process-guide/bylaws-guide.adoc >> @@ -0,0 +1,104 @@ >> +OpenDataPlane (ODP) Bylaws-Guide >> +================================ >> +:toc: >> + >> +:numbered!: >> +[abstract] >> +Abstract >> +-------- >> +This document is intended to guide a new application developer in >> +understanding the bylaws >> > dot is missing. > > Thanks > In some places you have "bylaws" but in other "by-laws". Dictionary says > that hyphen has to be used. > Please fix it everywhere in doc. Thanks - will unify > > > > + >> +The ODP project has established a set of by-laws defining the operational >> +processes by which direction of ODP resources is determined and how the >> product >> +is managed. >> + >> +The by-laws define roles, stewardship/management, patch approvals, voting >> +procedures, and reporting (Roadmap) requirements. >> + >> +Further details about ODP may be found at the http://opendataplane.org >> [ODP] >> +home page. >> + >> +:numbered: >> + >> +== Roles considered >> +=== Users >> > > How about name it: Users (ODP Applications developers). Maybe, we will likely have driver developer's, implementation developers and application developers, dont we need a term for all of them as users of the API > > > > +People that use the project and submit bugs and request new features to >> the >> +project. >> + >> +=== Contributors >> +All of the volunteers who are contributing time, code, documentation, or >> +resources to the project. A contributor that makes sustained, welcome >> +contributions to the project may be invited to become a maintainer, >> though the >> +exact timing of such invitations depends on many factors. >> + >> +If a contributor wants to move the project in direction X or add feature >> Y, and >> +that requires a lot of rewrite in the existing code-base then: >> + >> +* explain that in an email to the mailing list. >> +* send out RFCs (early and often) with example code, so the community >> (and >> +maintainers) can see what you want and say if it fits or not. >> + >> +The above helps find and solve common problems among contributors. >> + >> +=== Maintainer(s) >> +* The maintainer for a project have push rights to the main repo. Only >> one >> +maintainer. The most trustworthy sub-maintainer shall step in and take >> over the >> +maintainer ship as required. >> +* Sub-maintainer(s) one or many for the different modules in the project. >> +* Sub-maintainers shall focus on ensuring that the current code base has >> good >> +quality and review new patches to maintain that good quality. >> +* When Maintainers accept code, they have to deal with it until they die >> or rip >> +it out (so its important that they understand what the code does and why >> they >> +need it). The contributor shall convince the maintainer to take their >> code (the >> +maintainer should feel like he would be stupid to not accept the code…) >> + >> +=== Release Manager === >> + >> +* The RM shall publish a Release Plan on the roadmap. One week before the >> +release the candidate list will be reviewed. >> +* The RM is responsible for building consensus around the content of the >> +Release. >> + >> +== Roadmap >> +The roadmap shall state projected future releases and the expected >> content. >> + >> +== Steering Committee (SC) >> +* Maintaining the project’s shared resources, email lists and the >> homepage. >> > Maybe maintain is not right word here. Technically work operating of that > services > maintained by Linaro IT team. SC probably defines requirements for project > support services. Thanks, agree > > > +* Speaking on behalf of the project. >> +* Resolving license disputes regarding products of the project. >> +* Nominating new PMC members and committers. >> +* Maintaining these bylaws and other guidelines of the project. >> +* Planning the roadmap (shall state projected future releases and the >> expected >> +content). >> + >> +=== Patch approval >> +Reviewed-by is only replied to the list after inspecting the code. If >> you have >> +review comments they should be constructive and not just saying “no”. >> +Reviewed-by and Signed-off-by implies that you are co-responsible for >> any bugs >> +found in the code. >> + >> +If you don’t respond you are assumed to agree with the patch. >> + >> +== Voting == >> +Voting is necessary if consensus not has been reached. Must have >> established >> +quorum. >> + >> +* “Yes”, “Agree”,"+1" the action should be performed. >> +In general, this vote also indicates a willingness on the behalf of the >> voter in >> +“making it happen” >> + >> +* “Abstain” This vote indicates that the voter abstains. >> +The voter has no interest or does not participate in the vote. >> + >> +* “No”, “Disagree” "-1" the action should not be performed. >> +On issues where consensus is required, this vote counts as a veto. All >> vetoes >> +must contain an explanation of why the veto is appropriate. Vetoes with >> no >> +explanation are void. It may also be appropriate for a -1 vote to >> include an >> +alternative course of action. >> + >> +== Adding new features == >> + >> +If person X adds a new feature (API group X) then he should/could be >> asked to >> +be the maintainer for that feature. Code (old or new) is likely to be >> removed >> +if it is unmaintained. >> > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp > -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
diff --git a/doc/process-guide/Makefile.am b/doc/process-guide/Makefile.am index 54e2c1d..1ac32da 100644 --- a/doc/process-guide/Makefile.am +++ b/doc/process-guide/Makefile.am @@ -1,11 +1,13 @@ -TARGET = $(top_srcdir)/doc/output/release-guide.html +TARGET = $(top_srcdir)/doc/output/release-guide.html $(top_srcdir)/doc/output/bylaws-guide.html -EXTRA_DIST = release-guide.adoc +EXTRA_DIST = release-guide.adoc bylaws-guide.adoc all-local: $(TARGET) -$(TARGET): release-guide.adoc - @mkdir -p $(top_srcdir)/doc/output +$(top_srcdir)/doc/output/release-guide.html: release-guide.adoc + asciidoc -b html5 -a icons -a toc2 -a max-width=55em --out-file=$@ $< + +$(top_srcdir)/doc/output/bylaws-guide.html: bylaws-guide.adoc asciidoc -b html5 -a icons -a toc2 -a max-width=55em --out-file=$@ $< clean-local: diff --git a/doc/process-guide/bylaws-guide.adoc b/doc/process-guide/bylaws-guide.adoc new file mode 100644 index 0000000..91411da --- /dev/null +++ b/doc/process-guide/bylaws-guide.adoc @@ -0,0 +1,104 @@ +OpenDataPlane (ODP) Bylaws-Guide +================================ +:toc: + +:numbered!: +[abstract] +Abstract +-------- +This document is intended to guide a new application developer in +understanding the bylaws + +The ODP project has established a set of by-laws defining the operational +processes by which direction of ODP resources is determined and how the product +is managed. + +The by-laws define roles, stewardship/management, patch approvals, voting +procedures, and reporting (Roadmap) requirements. + +Further details about ODP may be found at the http://opendataplane.org[ODP] +home page. + +:numbered: + +== Roles considered +=== Users +People that use the project and submit bugs and request new features to the +project. + +=== Contributors +All of the volunteers who are contributing time, code, documentation, or +resources to the project. A contributor that makes sustained, welcome +contributions to the project may be invited to become a maintainer, though the +exact timing of such invitations depends on many factors. + +If a contributor wants to move the project in direction X or add feature Y, and +that requires a lot of rewrite in the existing code-base then: + +* explain that in an email to the mailing list. +* send out RFCs (early and often) with example code, so the community (and +maintainers) can see what you want and say if it fits or not. + +The above helps find and solve common problems among contributors. + +=== Maintainer(s) +* The maintainer for a project have push rights to the main repo. Only one +maintainer. The most trustworthy sub-maintainer shall step in and take over the +maintainer ship as required. +* Sub-maintainer(s) one or many for the different modules in the project. +* Sub-maintainers shall focus on ensuring that the current code base has good +quality and review new patches to maintain that good quality. +* When Maintainers accept code, they have to deal with it until they die or rip +it out (so its important that they understand what the code does and why they +need it). The contributor shall convince the maintainer to take their code (the +maintainer should feel like he would be stupid to not accept the code…) + +=== Release Manager === + +* The RM shall publish a Release Plan on the roadmap. One week before the +release the candidate list will be reviewed. +* The RM is responsible for building consensus around the content of the +Release. + +== Roadmap +The roadmap shall state projected future releases and the expected content. + +== Steering Committee (SC) +* Maintaining the project’s shared resources, email lists and the homepage. +* Speaking on behalf of the project. +* Resolving license disputes regarding products of the project. +* Nominating new PMC members and committers. +* Maintaining these bylaws and other guidelines of the project. +* Planning the roadmap (shall state projected future releases and the expected +content). + +=== Patch approval +Reviewed-by is only replied to the list after inspecting the code. If you have +review comments they should be constructive and not just saying “no”. +Reviewed-by and Signed-off-by implies that you are co-responsible for any bugs +found in the code. + +If you don’t respond you are assumed to agree with the patch. + +== Voting == +Voting is necessary if consensus not has been reached. Must have established +quorum. + +* “Yes”, “Agree”,"+1" the action should be performed. +In general, this vote also indicates a willingness on the behalf of the voter in +“making it happen” + +* “Abstain” This vote indicates that the voter abstains. +The voter has no interest or does not participate in the vote. + +* “No”, “Disagree” "-1" the action should not be performed. +On issues where consensus is required, this vote counts as a veto. All vetoes +must contain an explanation of why the veto is appropriate. Vetoes with no +explanation are void. It may also be appropriate for a -1 vote to include an +alternative course of action. + +== Adding new features == + +If person X adds a new feature (API group X) then he should/could be asked to +be the maintainer for that feature. Code (old or new) is likely to be removed +if it is unmaintained.
The bylaws were only recorded as part of the website, move them to git where they can be tracked. Signed-off-by: Mike Holmes <mike.holmes@linaro.org> --- doc/process-guide/Makefile.am | 10 ++-- doc/process-guide/bylaws-guide.adoc | 104 ++++++++++++++++++++++++++++++++++++ 2 files changed, 110 insertions(+), 4 deletions(-) create mode 100644 doc/process-guide/bylaws-guide.adoc