Skip to content

Latest commit

 

History

History
50 lines (38 loc) · 8.91 KB

bylaws.md

File metadata and controls

50 lines (38 loc) · 8.91 KB

The Edubadges 'by-laws'

a.k.a. the Communication guidelines

Our aim is to communicate as openly as possible, so open platforms are used for this. At the same time, there will also be a need for consultation exclusively within the working group, so there are multiple communication channels. Each channel has its own target group and purpose. The language of communication is Dutch. The language of the specification and discussions on the specification on GitHub is English.

  1. Open Education API website: The OOAPI site at https://openonderwijsapi.nl/en/ will be used mainly to provide clarification to interested parties. The site also provides references to the reference API, online documentation and the code repository. Communication will primarily be one-way, from the OOAPI project to the interested parties. It will not be possible to directly post or publish to the website through the community. The site indicates that the email address [email protected] or the community site can be used to provide feedback if desired.
  2. The general email address [email protected]: This address is used as the general email address for the OOAPI project. Email to this address will be delivered to members of the working group. This email address can be used by prospective group members to sign up as a member of the working group.
  3. Mailing list: This list serves as a discussion list for the OOAPI and is hosted by Google Groups. The list is not public and only list subscribers can post on the list or read the list archives. Parties interested in the specification and working group members are invited and added to this list by members of the working group. Each post is sent to all list subscribers and is stored in a private online archive. The list is not included in the Google list directory. The list manager is the [email protected] account, whose credentials are known to members of the working group.
  4. Community site at https://plus.google.com/u/1/communities/106455663981908394819: Google Plus Communities is used for the community platform. This is a public community site where all information can be found without having to sign in. However, if you want to submit a post or a comment, you must be a member of this community. This can be done by signing in with your Google+ account and sending a membership request. The site administrator reviews and accepts or rejects membership requests. This community is managed by the [email protected] account, whose credentials are known to members of the working group.
  5. The website https://www.edustandaard.nl/ and the ROSA-wiki at https://www.wikixl.nl/wiki/rosa/ promote the OOAPI standard: They inform about the specification, how it is connected to other standards in the context of HORA and ROSA, usage and implementations and documentation.

The working group will use this community site to make announcements, share minutes of meetings, and so on. The community can respond to this, ask questions or add new topics.

  • Github https://github.com/open-education-api: The specification is hosted on GitHub. Development of the specification, outstanding issues and a timeline for the delivery of a new version of the API are shared through GitHub. Two members of the working group are given the status of 'master committer' and ‘backup master committer’. These members are nominated from among the working group and are appointed by the other members of the working group. They are responsible for adding and deleting code from the GitHub repository. Everyone is free to use the repository and can provide their own code by sending a pull request to the master committers. SURFnet project staff will remain the owner of the GitHub repository for the duration of the project.

Rules on participation

This section describes how community members can contribute to the project, for instance through discussion, providing feedback, expanding the specification and ongoing development.

  • Contributing to the OOAPI specification; feedback on the OOAPI can be provided by the entire community through the community site. This is not reserved for the working group only.
  • Community members can expand the OOAPI during implementation by adding an extension. This extension will not yet be part of the specification. Working group members decide whether this extension can be included in the next version of the OOAPI standard.
  • Contributing to the code on GitHub; anyone can submit pull requests to one of the OOAPI code repositories. The working group decides on acceptance of code contributions.

Rules on decision-making

This section describes how decision-making within the project takes place. Bureau Edustandaard manages (the process of the) OOAPI standardisation and is therefore responsible for development and adoption of the specification. The working group has delegated responsibility for the daily task of community management, communication, developing and promoting the use of the OOAPI, i.e. the specification itself, the documentation, the reference implementation and the online demo. The working group decides on adding new members to the working group. The working group decides on minor and major adaptation and modification of the OOAPI specification.

The decision-making procedure is as follows: There are two forms of decision-making:

  • Decisions on the specification description on GitHub
  • Decisions on the method and the acceptance of proposed major changes within GitHub, for example, a release.

Decisions within GitHub For issues within the GitHub environment, the following applies: If an issue is submitted, the master committer has 5 days to prepare for handling the issue. The voting procedure is started within these 5 days so that the decision can be voted on. The decision in respect of which an issue is handled is recorded within the GitHub environment. See the info at https://openonderwijsapi.nl/en/community/

Other decisions Remote voting can take place online at any time through email using the mailing list [email protected] or can be send by email. Any working group member can submit a decision to be voted on. All working group members receive an email of the forthcoming vote. This notification specifies:

  • the matter which is the subject of the vote;
  • when the vote will take place;
  • and, if necessary, the timeframe within which a vote must be cast.

There must be a period of at least 7 days between the announcement of the vote and the time a vote can be cast. Only members of the working group can cast a vote. Voting can take place online OR at a meeting. If a member cannot attend the meeting, they must make their vote known before the meeting by sending an email to [email protected]. Votes cast after the meeting will not be taken into consideration in taking the decision. If there is a majority vote, the decision will be adopted. If there is no majority vote, or if a vote leads to discussion or a member of the working group appeals against the decision, the vote will be put as an agenda item for the next meeting of the working group. A working group member can appeal against a decision by formulating their objection and sharing it through the mailing list.

The following rules apply to decision-making:

  • Only institutions affiliated with SURFnet and 1 representative per institution have voting rights.
  • SURFnet is also represented in the working group and has 1 vote. The decision taken is recorded in the decisions list in the minutes or, if it concerns an online decision, is communicated via e-mail.

The working group informs Bureau Edustandaard by e-mail about major releases, the decision-making process that was followed and the acceptance of the releases by individual working group members. The Architecture council analyses the new release and executes a new ROSA scan in order to make relevant architectural changes transparent. After that the major release will be evaluated by the Standardisation council.

Compliancy rules: when are you in compliance with the specification?

This section describes how an institution or supplier can demonstrate that they are in compliance with the specification. Compliance with the specification is understood to mean:

  • All required fields for the end points have been filled in according to the data requirements. The specific version of the OOAPI being implemented must be specified;
  • Where optional fields are applied, they must be filled in according to the data requirements;
  • Documentation on own implementation is available online for at least the working group members. Compliance with the specification can be demonstrated with a badge stating 'complies with OOAPI'. Each version of the OOAPI will have its own 'complies with OOAPI Vx.x' badge so that it is clear which version of the specification it complies with.

Appendix A: Code of Conduct (COC)

The Open Education API project applies the following code of conduct: https://github.com/open-education-api/specification/blob/master/code-of-conduct.md