To follow what LF/AI requires with the Charter.
It has been drafted at https://wiki.lfai.foundation/display/NNSTREAM/NNStreamer+CONTRIBUTING+draft+of+2020.04
updated 2020-04-16
- Clarified "most senior among available committers", Line 45
(suggeted by @zhoonit)
- s/chairman/chairperson
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
# Technical Steering Committee
-Techinical Steering Committee (TSC) is reponsible for overseeing all techinical aspects of the project, NNStreamer, and its subsidiary projects in the same Github organization.
+Technical Steering Committee (TSC) is responsible for overseeing all technical aspects of the project, NNStreamer, and its subsidiary projects in the same Github organization.
+
+The initial TSC voting members are the committers of NNStreamer at the time of the first TSC meeting. Election or removal of TSC voting members should be approved by TSC voting. Except for approvals of license exceptions and the community charger amendments, approval of TCS voting requires approvals of more than half of present TSC voting members in a TSC meeting, which requires to have at least the half of the voting members present in the TSC meeting. Approvals of electronic TSC voting requires approvals of more than half of all TSC voting members. TSC may elect or replace the chairperson of the project with TSC voting.
+
+With unresolvable issues with TSC voting, a TSC voting member may inquire about the issues to the Linux Foundation Series managers.
+
+Each TSC voting member including a chairperson or its deputy has a single vote in TSC voting.
+
+The TSC voting members are:
+
+* MyungJoo Ham @myungjoo
+* Jijoong Moon @jijoongmoon
+* Geunsik Lim @leemgs
+* Jaeyun Jung @jaeyun-jung
+* Sangjung Woo @again4you
+* Wook Song @wooksong
+* Dongju Chae @dongju-chae
+* HyoungJoo Ahn @helloahn
+* Parichay Kapoor @kparichay
+* Gichan Jang @gichan-jang
+* Yongjoo Ahn @anyj0527
+* Jihoon Lee @zhoonit
+
+
+## TSC Meeting
+
+
+A TSC meeting is required to be publically announced (at least 10 days before the meeting) and publically accessible. A chairperson or its deputy, who is designated by a chairperson or the former chairperson, may announce and hold a TSC meeting. A deputy designated by a former resigning chairperson should hold a TSC meeting to elect a new chairperson and is relieved automatically by electing a new chairperson.
+
+A TSC meeting should be announced via the nnstreamer-announce LFAI mailing list (the mailing list). Other media (GitHub issues, gitter.im, social media, LFAI event calendar, and so on) may also be used along with the mailing list.
+
+A TSC meeting should be held at a publically accessible place. A TSC meeting is, by default, held conventionally (offline meeting) in a place where the chairperson or its deputy has announced. However, alternatively, a TSC meeting may be held virtually (audio or video conference) with publically available media that are declared with the meeting announcement. A conventionally-held TSC meeting may include audio or video conferences to help those who cannot present physically.
+
+A TSC meeting is, by default, recorded or scripted for the general public. The URLs or the contents of the recordings or scripts should be available via the mailing list. Alternatively, a live video stream may be broadcasted via methods declared by the mailing list.
+
+In the case of the unavailability of the mailing list, a pinned GitHub issue of https://github.com/nnstreamer/nnstreamer can be used instead.
+
+
+## Unavailability of a Chairperson or its Deputy
+A chairperson should assign its deputy or hold a TSC meeting to elect a successor when he/she resigns.
+
+If there is no chairperson or its deputy available, the most senior among available committers may and should announce and hold a TSC meeting to elect a chairperson. An available committer is a committer who has been submitting code commits or code reviews to the main project (nnstreamer.git) during the last 30 days. A senior committer is a committer who has committed codes to the main GitHub project (nnstreamer.git) before other available committers. Unavailability of chairperson and deputy can be declared via the mailing-list by a committer. The unavailability declaration becomes effective after the declaring committer tries to contact the chairperson or deputy personally, the declaration is acknowledged by other two or more committers, and there are no responses from chairperson or deputy via the mailing list or GitHub issues of the main project (nnstreamer.git) within 30 days. With the effective unavailability declaration, the most senior among available committers automatically becomes the deputy who holds the TSC meeting to elect a chairperson within the next 30 days. If the available senior committer fails to do this within the given 30 days after the effective declaration, the Linux Foundation Series manager may designate any TSC voting member of committer as a deputy chairperson and any TSC voting member or committer may contact Linux Foundation to initiate this process.
+
+
+
+## Contributors
+
+Anyone who has been contributed to the repository by submitting a pull-request and have it reviewed, accepted, and merged by committers is a contributor.
+
+Each contributor should comply with the [Code of Conduct](https://github.com/nnstreamer/nnstreamer/blob/master/CODE_OF_CONDUCT.md), this document (CONTRIBUTING.md), and [the Linux Foundation's policies](http://lfprojects.org/policies/).
+
+Every contributor is able and encouraged to review codes and to participate in other developmental activities.
+
+
+
+## Committers
+
+A committer is responsible for reviewing incoming pull-requests and is able to reject or approve pull requests. Note that contributors may review pull-requests, but they cannot reject it or vote for approval.
+
+A contributor may become a committer with approvals of more than half of the committers.
+
+A committer may be retired by approvals of more than half of the committers.
+
+Alternatively, TSC may decide to elect or to retire a committer with TSC voting as well or amend the rules on how to elect/retire committers.
+
+Each committer is also a contributor and should comply with the [Code of Conduct](https://github.com/nnstreamer/nnstreamer/blob/master/CODE_OF_CONDUCT.md), this document (CONTRIBUTING.md), and [the Linux Foundation's policies](http://lfprojects.org/policies/).
+
+The committers are:
+
+* MyungJoo Ham @myungjoo :beer: (maintainer)
+* Jijoong Moon @jijoongmoon :beer:
+* Geunsik Lim @leemgs :beer:
+* Jaeyun Jung @jaeyun-jung :beer:
+* Sangjung Woo @again4you :beer:
+* Wook Song @wooksong :beer:
+* Dongju Chae @dongju-chae :beer:
+* HyoungJoo Ahn @helloahn :beer:
+* Parichay Kapoor @kparichay :beer:
+* Gichan Jang @gichan-jang
+* Yongjoo Ahn @anyj0527
+* Jihoon Lee @zhoonit
+
+
+## Merging a pull-request
+
+[How to Contribute # Merge Criteria](Documentation/contributing.md#merge-criteria) describes how a pull-request may be merged or rejected by committers.
+
+In the above list, committers with :beer: have merging privilege.
+
+Granting or revoking merging privileges require the same procedure of electing or retiring a committer.
+
+A maintainer [Maintainers](MAINTAINERS.md#maintainer) is designated by TSC among committers.
+
+Each sub-project may have its own maintainer in the sub-project.
+
# Links to related information
## Contributing
-See [Contributing](Documentation/contributing.md) for information about coding styles, making pull requests, and more.
+See [How to Contribute](Documentation/contributing.md) for information about coding styles, making pull requests, and more.
## Developers
For more information, please refer to [coding-convention.md](coding-convention.md).
+For C code, you may use [gst-indent](../tools/development/gst-indent).
+For C++ code, you may apply clang-format with the given [.clang-format](../.clang-format) file.
+For C/C++ header files, we do not require strict style rules, but it is recommended to apply such rules.
+
+We do not have explicit and strict styling rules for other programming languages, yet.
+
## Code Reviews and PRs
-Please review incoming PRs; regardless whether you are a maintainer, a designated reviewer, or just a passer-by.
+You are encouraged to review incoming PRs; regardless whether you are a committer, a designated reviewer, or just a passer-by.
-If you are a maintainer or reviewer of the specific component, you are obligated to review incoming related PRs within some reasonable time frame.
-However, even if you are not a reviewer (designated by committer or maintainers) or maintainer, as long as you are in this project, you need to give feedback on PRs especially if you are working on similar topics/components.
+If you are a committer or a reviewer of the specific component, you are obligated to review incoming related PRs within some reasonable time frame.
+However, even if you are not a reviewer (designated by committer or submitter), as long as you are in this project, you need to give feedback on PRs especially if you are working on similar topics/components.
The submitter has the first responsibility of keeping the created PR clean and neat (rebase whenever there are merge conflicts), following up the feedback, testing when needed.
### Additional requirements for codes
* Each feature should come with a rich set of test cases that can be executed as unit tests during build. If the feature is more invasive or richer, you need more and richer test cases. Refer to other test cases in /tests directory, which use either GTest or SSAT.
-* Try to stick with C89. Try to avoid introducing additional dependencies of libraries. If you are going to use C++ or additional libraries, your codes may be located at /ext/* so that they can be "optional" features.
+* When new test cases are introduced, the number of new negative test cases should be larger than or equal to the number of new positive test cases.
+* For C-code, try to stick with C89.
+* For C++-code, try to be compatible with C++11. C++ code should be able to be built optionally. In other words, by disabling C++ build option, we should be able to build the whole system without C++ compilers.
+* Avoid introducing additional dependencies of libraries. If you are going to use additional libraries, your codes may be located at /ext/* so that they can be "optional" features.
* If your functions or structs/classes are going to be accessed by other modules or NNStreamer users, provide full descriptions of all entries with Doxygen.
* Passing all the tests of TAOS-CI is a necessary condition, but not a satisfying condition.
* It has passed all the tests defined for TAOS-CI.
- This includes unit tests and integration tests in various platforms and different static analysis tools.
- Note that one of the tests includes the "Signed-off-by" check, which means that the author has agreed with [Code of Conduct](../CODE_OF_CONDUCT.md). You may need to refer to later section.
-* At least TWO official reviewers have approved the PR.
- - This does not guarantee accepts. This is a necessary condition, not sufficient.
+* At least TWO committers (reviewers with voting rights, elected by TSC or other committers) have approved the PR.
+ - This is a necessary condition, not sufficient.
- If the PR touches sensitive codes or may affect wide ranges of components, reviewers will wait for other reviewers to back them up.
- If the PR is messy, you will need to wait indefinitely to get reviews.
- Apply general rules of git commits and common senses.
- Do not write a lengthy commit. Apply a single commit per PR if you are new to the community. Have a single topic per commit. Provide enough background information and references. And so on.
* There is no rejections from any official reviewers.
* There is no pending negative feedbacks (unresolved issues) from reviewers.
+* A committer with merging privilege will, then, be able to merge the given PR.
## Signing off commits
# Definitions of Roles
-## Maintainer (TSC Chairman as of 2020.3.27)
+## Maintainer
-- May override to merge a pull-request or push/revert commits.
-- Decide when/where/how to vote which policy/architecture proposals.
-- May propose a committer removal.
-- Have all reviewer privilieges.
+- A committer that is also an arbiter for other committers in the Github/Git repositories.
+- May override merging criteria to merge/close a pull-request or to push/revert a commit.
-## Reviewer (Committer)
+## Committer (previously Reviewer)
-- May reject a pull-request, which prohibits merging.
+- May reject a pull-request, which prohibits merging. "Veto"
- May vote for an approval.
-- May merge a pull-request if it has enough number of approval-votes from reviewers or maintainers (2 or more).
+- (Requires merge privilege) May merge a pull-request if it has enough number of approval-votes from committers (2 or more).
- May propose new committers among well-known contributors and vote for new committers
- Vote for a committer removal.
-- Propose and vote for policies and architecture.
- The ability of reject and merge may be limited to a few subdirectories.
- The list of reviewers and their subdirectories is at [.github/CODEOWNERS].
projects / platform / upstream / nnstreamer.git / commitdiff