| Message ID | 1452625179-10228-1-git-send-email-mike.holmes@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
ping On 12 January 2016 at 13:59, Mike Holmes <mike.holmes@linaro.org> wrote: > The by-laws 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> > --- > v2: > Comments from Maxim > > doc/process-guide/Makefile.am | 6 +- > doc/process-guide/bylaws-guide.adoc | 119 > ++++++++++++++++++++++++++++++++++++ > 2 files changed, 123 insertions(+), 2 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 95915c0..9fc3b80 100644 > --- a/doc/process-guide/Makefile.am > +++ b/doc/process-guide/Makefile.am > @@ -1,8 +1,10 @@ > include ../Makefile.inc > > -TARGET = release-guide.html > +TARGET = bylaws-guide.html \ > + release-guide.html > > -EXTRA_DIST = release-guide.adoc > +EXTRA_DIST = bylaws-guide.adoc \ > + release-guide.adoc > > all-local: $(TARGET) > > diff --git a/doc/process-guide/bylaws-guide.adoc > b/doc/process-guide/bylaws-guide.adoc > new file mode 100644 > index 0000000..509e479 > --- /dev/null > +++ b/doc/process-guide/bylaws-guide.adoc > @@ -0,0 +1,119 @@ > +:doctitle: OpenDataPlane (ODP) By-laws-Guide > +:description: This document is intended to guide a new application > developer + > +in understanding the by-laws > + > +++++ > +<script> > + > (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ > + (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new > Date();a=s.createElement(o), > + > m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) > + })(window,document,'script','//www.google-analytics.com/analytics.js > ','ga'); > + > + ga('create', 'UA-16756069-15', 'auto'); > + ga('send', 'pageview'); > + > +</script> > +++++ > + > +:toc: > +:numbered!: > +[abstract] > +Abstract > +-------- > +This document is intended to guide a new application developer in > +understanding the by-laws. > + > +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) > +* Defining the requirements for 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 by-laws 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 > > -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
On 01/16/2016 00:01, Mike Holmes wrote: > ping > What is the answer about google analytic java script here? Maxim. > On 12 January 2016 at 13:59, Mike Holmes <mike.holmes@linaro.org > <mailto:mike.holmes@linaro.org>> wrote: > > The by-laws 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 > <mailto:mike.holmes@linaro.org>> > --- > v2: > Comments from Maxim > > doc/process-guide/Makefile.am | 6 +- > doc/process-guide/bylaws-guide.adoc | 119 > ++++++++++++++++++++++++++++++++++++ > 2 files changed, 123 insertions(+), 2 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 95915c0..9fc3b80 100644 > --- a/doc/process-guide/Makefile.am > +++ b/doc/process-guide/Makefile.am > @@ -1,8 +1,10 @@ > include ../Makefile.inc > > -TARGET = release-guide.html > +TARGET = bylaws-guide.html \ > + release-guide.html > > -EXTRA_DIST = release-guide.adoc > +EXTRA_DIST = bylaws-guide.adoc \ > + release-guide.adoc > > all-local: $(TARGET) > > diff --git a/doc/process-guide/bylaws-guide.adoc > b/doc/process-guide/bylaws-guide.adoc > new file mode 100644 > index 0000000..509e479 > --- /dev/null > +++ b/doc/process-guide/bylaws-guide.adoc > @@ -0,0 +1,119 @@ > +:doctitle: OpenDataPlane (ODP) By-laws-Guide > +:description: This document is intended to guide a new > application developer + > +in understanding the by-laws > + > +++++ > +<script> > + > (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ > + (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new > Date();a=s.createElement(o), > + > m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) > + > })(window,document,'script','//www.google-analytics.com/analytics.js > <http://www.google-analytics.com/analytics.js>','ga'); > + > + ga('create', 'UA-16756069-15', 'auto'); > + ga('send', 'pageview'); > + > +</script> > +++++ > + > +:toc: > +:numbered!: > +[abstract] > +Abstract > +-------- > +This document is intended to guide a new application developer in > +understanding the by-laws. > + > +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) > +* Defining the requirements for 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 by-laws 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 > > > > > -- > Mike Holmes > Technical Manager - Linaro Networking Group > Linaro.org <http://www.linaro.org/>***│ *Open source software for ARM SoCs > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp
I have not been able to catch Shovan, I will post again and remove the java snippet, it can be a follow on if needed. On 16 January 2016 at 03:21, Maxim Uvarov <maxim.uvarov@linaro.org> wrote: > On 01/16/2016 00:01, Mike Holmes wrote: > >> ping >> >> > What is the answer about google analytic java script here? > > Maxim. > > On 12 January 2016 at 13:59, Mike Holmes <mike.holmes@linaro.org <mailto: >> mike.holmes@linaro.org>> wrote: >> >> The by-laws 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 >> <mailto:mike.holmes@linaro.org>> >> >> --- >> v2: >> Comments from Maxim >> >> doc/process-guide/Makefile.am | 6 +- >> doc/process-guide/bylaws-guide.adoc | 119 >> ++++++++++++++++++++++++++++++++++++ >> 2 files changed, 123 insertions(+), 2 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 95915c0..9fc3b80 100644 >> --- a/doc/process-guide/Makefile.am >> +++ b/doc/process-guide/Makefile.am >> @@ -1,8 +1,10 @@ >> include ../Makefile.inc >> >> -TARGET = release-guide.html >> +TARGET = bylaws-guide.html \ >> + release-guide.html >> >> -EXTRA_DIST = release-guide.adoc >> +EXTRA_DIST = bylaws-guide.adoc \ >> + release-guide.adoc >> >> all-local: $(TARGET) >> >> diff --git a/doc/process-guide/bylaws-guide.adoc >> b/doc/process-guide/bylaws-guide.adoc >> new file mode 100644 >> index 0000000..509e479 >> --- /dev/null >> +++ b/doc/process-guide/bylaws-guide.adoc >> @@ -0,0 +1,119 @@ >> +:doctitle: OpenDataPlane (ODP) By-laws-Guide >> +:description: This document is intended to guide a new >> application developer + >> +in understanding the by-laws >> + >> +++++ >> +<script> >> + >> >> (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ >> + (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new >> Date();a=s.createElement(o), >> + >> >> m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) >> + })(window,document,'script','// >> www.google-analytics.com/analytics.js >> <http://www.google-analytics.com/analytics.js>','ga'); >> >> + >> + ga('create', 'UA-16756069-15', 'auto'); >> + ga('send', 'pageview'); >> + >> +</script> >> +++++ >> + >> +:toc: >> +:numbered!: >> +[abstract] >> +Abstract >> +-------- >> +This document is intended to guide a new application developer in >> +understanding the by-laws. >> + >> +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) >> +* Defining the requirements for 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 by-laws 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 >> >> >> >> >> -- >> Mike Holmes >> Technical Manager - Linaro Networking Group >> Linaro.org <http://www.linaro.org/>***│ *Open source software for ARM >> SoCs >> >> >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/lng-odp >> > > _______________________________________________ > 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 95915c0..9fc3b80 100644 --- a/doc/process-guide/Makefile.am +++ b/doc/process-guide/Makefile.am @@ -1,8 +1,10 @@ include ../Makefile.inc -TARGET = release-guide.html +TARGET = bylaws-guide.html \ + release-guide.html -EXTRA_DIST = release-guide.adoc +EXTRA_DIST = bylaws-guide.adoc \ + release-guide.adoc all-local: $(TARGET) diff --git a/doc/process-guide/bylaws-guide.adoc b/doc/process-guide/bylaws-guide.adoc new file mode 100644 index 0000000..509e479 --- /dev/null +++ b/doc/process-guide/bylaws-guide.adoc @@ -0,0 +1,119 @@ +:doctitle: OpenDataPlane (ODP) By-laws-Guide +:description: This document is intended to guide a new application developer + +in understanding the by-laws + +++++ +<script> + (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ + (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), + m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) + })(window,document,'script','//www.google-analytics.com/analytics.js','ga'); + + ga('create', 'UA-16756069-15', 'auto'); + ga('send', 'pageview'); + +</script> +++++ + +:toc: +:numbered!: +[abstract] +Abstract +-------- +This document is intended to guide a new application developer in +understanding the by-laws. + +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) +* Defining the requirements for 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 by-laws 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 by-laws 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> --- v2: Comments from Maxim doc/process-guide/Makefile.am | 6 +- doc/process-guide/bylaws-guide.adoc | 119 ++++++++++++++++++++++++++++++++++++ 2 files changed, 123 insertions(+), 2 deletions(-) create mode 100644 doc/process-guide/bylaws-guide.adoc