Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MarkDown Lint fixes #251

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

MarkDown Lint fixes #251

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
137 changes: 68 additions & 69 deletions CONTRIBUTE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,12 +1,12 @@
# Contributing to Moodle on Azure
# Contributing to Moodle on Azure

The TL;DR version is:

* We are a community project
* We seek to make decisions through community consensus
* We prefer debate through gradual improvement through pull requests to endless discussion about the "perfect" solution
* We are a meritocracy, not a democracy
* We welcome all your contributions including but not limited to feature requests, bug-reports, documentation and code
* We are a community project
* We seek to make decisions through community consensus
* We prefer debate through gradual improvement through pull requests to endless discussion about the "perfect" solution
* We are a meritocracy, not a democracy
* We welcome all your contributions including but not limited to feature requests, bug-reports, documentation and code

## How the project is managed

Expand All @@ -20,23 +20,23 @@ The short version of how to contribute to this project is "just do
it". Where "it" can be defined as any valuable contribution (and to be
clear, asking questions is a valuable contribution):

* ask questions
* provide feedback
* write or update documentation
* help new users
* recommend the project to others
* test the code and report bugs
* fix bugs and issue pull requests
* give us feedback on required features
* write and update the software
* create artwork
* translate to different languages
* anything you can see that needs doing
* ask questions
* provide feedback
* write or update documentation
* help new users
* recommend the project to others
* test the code and report bugs
* fix bugs and issue pull requests
* give us feedback on required features
* write and update the software
* create artwork
* translate to different languages
* anything you can see that needs doing

Most contributions require you to agree to a Contributor License
Agreement (CLA) declaring that you have the right to, and actually do,
grant us the rights to use your contribution. For details, visit
https://cla.microsoft.com.
[https://cla.microsoft.com].

When you submit a pull request, a CLA-bot will automatically determine
whether you need to provide a CLA and decorate the PR appropriately
Expand Down Expand Up @@ -79,8 +79,8 @@ This is an open source project. We have a few mantras to ensure
efficient collaboration, these mostly boil down to ensuring good
visibility into the communities goals. These include:

* If it didn't happen in public, it didn't happen
* Scratch your own itch
* If it didn't happen in public, it didn't happen
* Scratch your own itch

### If it didn't happen in public, it didn't happen (aka full transparency)

Expand All @@ -100,34 +100,34 @@ This is an open source project. We welcome feature requests and, as a
community, we will provide feedback on whether we intend to work on it
or not. To this end we categories feature requests in one of 4 ways:

* Priority 0 (will address)
* Priority 1 (may address)
* Priority 2 (maybe one day)
* wontfix (out of scope)
* Priority 0 (will address)
* Priority 1 (may address)
* Priority 2 (maybe one day)
* wontfix (out of scope)

Using these priorities it is easy for community members to decide
where to spend their time. For example:

* Priority 0 items are actively being worked on by at least one
community member. Others are welcome to contribute as appropriate
(reviews are particularly important)
* Priority 1 items are seen as important and are likely to be worked
on in the short to medium term, but there is no community member
active on the project at this time. Community members are welcome
to take ownership of these issues and propose a solution that they
intend to implement. If the community accepts the proposal then it
will become a Priority 0 issue.
* Priority 2 items are seen as interesting proposals that are not in
conflict with the projects goals but are unlikely to be worked on
by any existing communty members. Community members who have a
need for these items are strongly encouraged to identify
themselves and offer a proposal for a solution. If there is enough
support within the existing community this item can become a
Priority 0 under your leadership.
* Wontfix items are considered out of scope for this project.
Community members should seek to solve the problem in different
ways. Often this will mean contribution to Moodle itself or a
plugin that is external to this community.
* Priority 0 items are actively being worked on by at least one
community member. Others are welcome to contribute as appropriate
(reviews are particularly important)
* Priority 1 items are seen as important and are likely to be worked
on in the short to medium term, but there is no community member
active on the project at this time. Community members are welcome
to take ownership of these issues and propose a solution that they
intend to implement. If the community accepts the proposal then it
will become a Priority 0 issue.
* Priority 2 items are seen as interesting proposals that are not in
conflict with the projects goals but are unlikely to be worked on
by any existing communty members. Community members who have a
need for these items are strongly encouraged to identify
themselves and offer a proposal for a solution. If there is enough
support within the existing community this item can become a
Priority 0 under your leadership.
* Wontfix items are considered out of scope for this project.
Community members should seek to solve the problem in different
ways. Often this will mean contribution to Moodle itself or a
plugin that is external to this community.

## Community roles

Expand All @@ -139,15 +139,15 @@ Users self-identify by using our software and documentation. Their
responsibilities are to benefit from our work, but we welcome
contributions from users, such as:

* Ask questions
* Answer questions
* Feature requests
* Bug reports
* Design reviews
* Planning reviews
* Evangelize the project
* and more...
* Ask questions
* Answer questions
* Feature requests
* Bug reports
* Design reviews
* Planning reviews
* Evangelize the project
* and more...

Some users will become more involved with the project, those users
become Contributors.

Expand All @@ -158,13 +158,13 @@ project. Their responsibilities are to help the project be succesful
by ensuring that our work matches the needs of our users.
Possible contributions can include:

* Everything a User might contribute
* Remove blocks for users
* Provide design input
* Review pull requests
* Implement features
* Triage questions, feature requests and bug reports
* and more...
* Everything a User might contribute
* Remove blocks for users
* Provide design input
* Review pull requests
* Implement features
* Triage questions, feature requests and bug reports
* and more...

Some contributors will become very engaged and therefore become an
essential part of the community, these contributors will become
Expand All @@ -177,11 +177,11 @@ themselves into our process to ensure they run well. The goal is to
empower our contributors who in turn focus on delighting our users.
Maintainers contributions may include:

* Everyting Users and Contributors do
* Merge pull requests where appropriate
* Seek community consensus where conflict occurs
* Remove blocks for contributors
* and more...
* Everyting Users and Contributors do
* Merge pull requests where appropriate
* Seek community consensus where conflict occurs
* Remove blocks for contributors
* and more...

## Pull requests, Review and Merges

Expand All @@ -193,8 +193,8 @@ reviews, that is a community wide responsibility.
We operate under two models of review process as appropriate to each
circumstance:

* Merge then Review (our preferred model)
* Review then Merge
* Merge then Review (our preferred model)
* Review then Merge

### Merge Then Review

Expand Down Expand Up @@ -233,4 +233,3 @@ Where a change is on the critical path or it is potentiall
contriversial maintainers should request reviews using the GitHub
tooling. The last reviewer to sign-off on the pull request will merge
the pull request.

Loading