-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Create Contributions_and_Modifications.md
- Loading branch information
Showing
1 changed file
with
61 additions
and
0 deletions.
There are no files selected for viewing
61 changes: 61 additions & 0 deletions
61
Contributions_and_Modifications/Contributions_and_Modifications.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,61 @@ | ||
Arm Education has made the PPT branding tool open for modification and additions. Contributions are an important part of our materials, and our goal is to make it as simple as possible to become a contributor. | ||
|
||
You can make contributions to lecture and labs. Arm Education uses the following license - [License](https://github.com/arm-university/LEGv8-ISA-Simulator/blob/main/License/LICENSE.md) | ||
|
||
To encourage collaboration, as well as robust, consistent and maintainable content, we have developed a set of guidelines for contributing to these materials. | ||
|
||
|
||
### How to contribute | ||
Each program has a team of maintainers who provide [guidance]() and direction to contributors. This team is responsible for helping you get your changes in, as well as controlling the overall quality and consistency of the software. | ||
|
||
We accept contributions in the form of pull requests. For contributions that span multiple materials, multiple reviewers may be necessary. After reviews are complete, we test the changes. The testing includes but is not limited to: functional correctness, code style or formatting and regressions, such as code size increase as well as a review of any content amendments. If any of the tests fail, more work will be needed before we accept the contribution. | ||
|
||
By creating a pull request on GitHub, you agree to license your contributions under the same license as the original material. This is commonly referred to as "inbound=outbound". This enables contributions to happen in a quick and effortless way and encourages collaboration. | ||
|
||
Pull requests on GitHub have to meet the following requirements to keep the code, content and commit history clean: | ||
|
||
- Commits must always contain a proper description of their content. Start with a concise one-line description. Then, elaborate on reasoning of the choices made, descriptions for reviewers and other information that might otherwise be lost. | ||
- You should always write commits that allow publication. They must not contain confidential information, references to private documents, links to intranet locations or rude language. | ||
- All new features, content changes and enhancements require explanation about the change and user guides (for the labs) for us to accept them. Please link each pull request to all relevant documentation. | ||
- Comment in the pull request on every change (rebase or new commits). This helps reviewers to be up to date with changes. | ||
- Pull requests should fix a bug, add a feature or change content. | ||
- Smaller pull requests are easier to review and faster to integrate. | ||
|
||
If commits do not follow the above guidelines, we may request that you modify the commit history (often to add more details to address what and why rather than how). | ||
|
||
### AUP maintainers | ||
The maintainers are a small group of Arm engineers. Their primary role is to progress contributions, both internal and external, from the initial pull request state through to released code. | ||
|
||
Responsibilities: | ||
|
||
- Ensure the relevant stakeholders review pull requests. | ||
- Guide contributors both technically and procedurally. | ||
- Review pull requests. | ||
- Merge pull requests into the requested branches. | ||
- Make periodic patch and feature releases. | ||
|
||
### Tips | ||
- The maintainers and reviewers are your friends. It's important to realize that we all share a common goal and honest feedback is constructive feedback. | ||
- Larger contributions take longer to be accepted than smaller ones. The best contributions are small and purposeful, achieving a single goal. We may ask you to split up a contribution if it contains multiple unrelated changes. | ||
|
||
### Contributions | ||
|
||
Before contributing an enhancement (for example, a new lab or additional content), please review the contributions made to date to avoid duplication of work, as we or others might be working on a related feature. | ||
|
||
We can only accept contributions through GitHub if you create a pull request from forked or cloned versions of our repository. This allows us to review the contributions in an easy-to-use and reliable way, under public scrutiny. | ||
|
||
Please create separate pull requests for each topic; each pull request needs a clear unity of purpose. In particular, separate code formatting and style changes from functional changes. This makes each pull request’s true contribution clearer, so review is quicker and easier. | ||
|
||
### Reporting bugs | ||
|
||
You can submit bugs on directly on GitHub. | ||
|
||
The bug report should be reproducible (fails for others) and specific (where and how it fails). We will close insufficient bug reports. | ||
|
||
We copy issues reported on GitHub to our internal tracker and regularly triage them. | ||
|
||
For more information about how to contribute, please see our workflow. | ||
|
||
### Workflow | ||
|
||
All content and code changes and additions to Arm Education material is handled through GitHub and is subject to a QA process. If you want to contribute, either by adding features or by fixing bugs, please see the [workflow](https://github.com/arm-university/LEGv8-ISA-Simulator/blob/main/Contributions_and_Modifications/workflow.pdf). |