Contribution policy

.github/ISSUE_TEMPLATE/bug_report.md

@@ -2,7 +2,7 @@
 name: Bug report
 about: Create a report to help us improve
 title: ''
-labels: ''
+labels: 'bug'
 assignees: ''
 
 ---

.github/ISSUE_TEMPLATE/discussion.md

@@ -0,0 +1,25 @@
+---
+name: Question, Feature, Documentation
+labels: 'question'
+about: Ask question, request feature or documentation update
+---
+
+### Thank you for taking the time to share your thoughts with us.
+
+We welcome all suggestions for new features or documentation updates
+helping others to make better use of this project.
+
+As with any other topic you'd like to discuss with the community,
+we'd primarily like to invite you to [open a discussion](https://github.com/open-quantum-safe/oqs-provider/discussions)
+item with your concern.
+
+If you have a bug to report please use the [Bug report template](https://github.com/open-quantum-safe/oqs-provider/issues/new?assignees=&labels=&projects=&template=bug_report.md&title=).
+
+If you have an issue with the project that does not qualify as a bug
+and have already explored the code to the extent that you can make a
+proposal how to handle the issue, please feel free to open a
+"blank issue" providing all information you have already collected.
+
+Please remember to tell us which code version/branch you are using and
+then briefly describe the issue and proposal how to resolve it if
+available.

GOVERNANCE.md

@@ -0,0 +1,70 @@
+# Governance
+
+## Foreword
+
+This file documents the governance guidelines used for this project. It is principally concerned with defining the roles of project contributors, the associated rights and responsibilities, and the process for transitioning between them. As such, this document is written in a fairly formal and precise tone, so as to be succint and unambiguous. This should not be interpreted as a lack of warmth on the part of the OQS team---we're really quite friendly! We do not intend to act as gatekeepers by laying out this tier of roles and the associated rules. Instead, we hope that clearly defining these roles and the processes for attaining them shows contributors a clear path by which to become more involved in project governance, if they so wish. We welcome all questions, discussions, and contributions, and we would love to have more people on board.
+
+We recognize that some of the policies discussed here can seem intimidating---for instance, revocation of privileges or code of conduct violations. It is our hope that we don't have to rely on these guidelines; however, we believe that it is important to have them in place should they be needed.
+
+## Roles
+
+The following roles exist in the project:
+
+1. Maintainer: Person with GitHub administrative rights.
+
+2. Committer: Person with GitHub "Write" privileges; this entails the right and obligation to review PRs by Contributors and to actively participate in discussions.
+
+3. Contributor: Person that has contributed code.
+
+4. Users: Person using the project passively or actively, e.g., by participating in discussions.
+
+## Relationships between roles
+
+Any User may also be a Contributor. Any Contributor may also be a Committer. Any Committer may also be a Maintainer. A Maintainer must be a Committer.
+
+## Change of role
+
+Any User may become a Contributor by creating a pull request (PR) and getting it successfully reviewed and merged by Committers.
+
+Any Contributor can become a Committer by contributing sufficient code and displaying deep subject matter knowledge in discussions such that a majority of Committers vote for this change of role. A Maintainer can veto such a vote. Such a veto can be overruled by a 2/3 majority of Committers.
+
+As such a voting decision may be considered subjective, Contributors striving to become Committers are encouraged to ask for advice by Committers as to what---if anything---should be done to attain this status (additional to already documented knowledge in contributions). Baseline requirements for contributions are documented in [CONTRIBUTING.md](CONTRIBUTING.md). Any Contributor can create a discussion item to request a vote to become Committer.
+
+Any Committer can become a Maintainer by majority vote of voting Committers. A current Maintainer can veto such a vote. Such a veto can be overruled by a 2/3 majority of all Committers.
+
+A Maintainer is not permitted to remove another Maintainer's GitHub privileges.
+
+A Committer may be automatically moved to Contributor status if not actively contributing by discussion or PR review during the last 90 days or by voluntarily suspending this status (e.g., by taking a ["Leave of absence"](#leave-of-absence)). If a Maintainer loses or relinquishes the Committer status and, hence, the Maintainer status, the Committers have to determine whether a new Maintainer needs to be elected.
+
+Any person violating the [code of conduct](CODE_OF_CONDUCT.md], consistently not fulfilling the role responsibilities or other reasons can lose the role held if a simple majority of Committers votes for such removal and no Maintainer vetos that decision. If a Maintainer is to be removed from that role a 2/3 majority of Committers must agree.
+
+Depending on the reason for removal, a Maintainer may be converted to Emeritus status. Emeritus Maintainers may still be consulted on some project matters, and can be returned to Maintainer status if their availability changes and a simple majority of Committers agrees.
+
+## Leave of absence
+
+Any Committer may voluntarily step down from the role for a documented period of time, losing voting rights for that time period. The period is documented in this file next to the person's name below.  At the end of this time period, the Committer automatically regains their voting rights.
+
+A leave of absence may not be longer than a year. If the Committer needs to be away for longer than that, they must step down from that role unconditionally, and regaining that role becomes subject of normal procedures to become Committer, as described in ["Change of role"](#change-of-role) above.
+
+## Voting
+
+Change of role or changes to this document is subject to voting.
+
+Votes are to be executed by way of open GitHub discussions. No quorum is needed for votes open for 4 weeks. Urgent matters may be decided by majority vote among Maintainers or 2/3 majority by all Committers within an arbitrary voting period.
+
+## Documentation of roles
+
+Current Maintainers and Committers are to be documented below by way of reference to their GitHub handles.
+
+### Maintainers
+
+@baentsch
+@dstebila
+
+### Committers
+
+@baentsch
+@bhess
+@dstebila
+@thb-sb
+@christianpaquin