|
1 | 1 | # Contributing to Technical Documentation
|
2 | 2 |
|
3 |
| -🙇♀️ Thank you for contributing! |
| 3 | +## Introduction |
4 | 4 |
|
5 |
| -We – the maintainers and contributors of this project – understand that a Technical Documentation like this can only be set in collaboration with as many public technologists, policy makers and interested folk as possible. Thus we appreciate your input, enjoy feedback and welcome improvements to this project and are very open to collaboration. |
| 5 | +This document outlines the formal procedures for contributing to the Technical Documentation project. As a national technical specification, this documentation requires rigorous standards of contribution and collaboration to ensure accuracy, completeness, and compliance with relevant regulations. |
6 | 6 |
|
7 |
| -We love issues and pull requests from everyone. |
| 7 | +## Official Communication Channels |
8 | 8 |
|
9 |
| -## Problems, suggestions and questions in Issues |
| 9 | +Contributors are advised to report issues, propose modifications, or request clarifications through the official GitHub Issue tracking system: [GitHub Issues for publiccode.yml](https://github.com/italia/publiccode.yml/issues). Each submission must adhere to standardized documentation protocols. |
10 | 10 |
|
11 |
| -Please help development by reporting problems, suggesting changes and asking questions. To do this, you can [create a GitHub Issue](https://help.github.com/articles/creating-an-issue/) for this project in the [GitHub Issues for publiccode.yml](https://github.com/italia/publiccode.yml/issues). |
| 11 | +Contributing does not necessarily require modifications to the existing documentation; valuable contributions include identification of inconsistencies, clarification requests, and technical inquiries. |
12 | 12 |
|
13 |
| -You don't need to change any of our documentation to be a contributor! |
| 13 | +## Contribution Process |
14 | 14 |
|
15 |
| -## Documentation and code in Pull Requests |
| 15 | +To contribute content or code modifications to the Technical Documentation, adherence to the following protocol is required: |
16 | 16 |
|
17 |
| -If you want to contribute to IT-Wallet Technical Documentation you should make a Pull Request. |
| 17 | +### Documentation Submission Requirements |
18 | 18 |
|
19 |
| -If you never used GitHub, get up to speed with [Understanding the GitHub Flow](https://guides.github.com/introduction/flow/) or follow one of the great free interactive courses in the [GitHub learning lab](https://lab.github.com/) on working with GitHub and working with reStructuredText (RST), the syntax this project's documentation is in. |
| 19 | +Contributions to this project must be submitted via the GitHub Pull Request mechanism. Contributors unfamiliar with GitHub procedures are directed to review the [GitHub Flow documentation](https://guides.github.com/introduction/flow/) or complete relevant training modules in the [GitHub learning lab](https://lab.github.com/). |
20 | 20 |
|
21 |
| -This project is [licenced CC-0](LICENSE), which essentially means that the project, along with your contributions is in the Public Domain in whatever jusrisdiction possible, and everyone can do whatever they want with it. |
| 21 | +This documentation is published under [CC-0 license](LICENSE), designating it as Public Domain content within applicable jurisdictions. All contributions are subject to the same licensing terms. |
22 | 22 |
|
23 |
| -### 1. Make your changes |
| 23 | +### Procedural Guidelines |
24 | 24 |
|
25 |
| -This project uses the [**GitFlow branching model** and workflow](http://nvie.com/posts/a-successful-git-branching-model/). When you've forked this repository, please make sure to create a feature branch following the GitFlow model. |
| 25 | +#### 1. Implementation of Modifications |
26 | 26 |
|
27 |
| -Add your changes in commits [with a message that explains them](https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message). Document choices or decisions you make in the commit message, this will enable everyone to be informed of your choices in the future. |
| 27 | +This repository implements the [**GitFlow branching model** and workflow](http://nvie.com/posts/a-successful-git-branching-model/). Contributors must create feature branches in accordance with this model when submitting modifications. |
28 | 28 |
|
29 |
| -### 2. Pull Request |
| 29 | +All changes must be documented with comprehensive [commit messages](https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message) detailing: |
| 30 | +- The nature of the modification |
| 31 | +- Technical justification for the change |
| 32 | +- References to relevant standards or requirements |
30 | 33 |
|
31 |
| -When submitting the pull request, please accompany it with a description of the problem you are trying to address and the issue numbers that this Pull Request fixes/addresses. |
| 34 | +#### 2. Submission Protocol |
32 | 35 |
|
33 |
| -### 3. Improve |
| 36 | +Pull Requests must include: |
| 37 | +- A formal description of the addressed technical issue |
| 38 | +- References to corresponding issue numbers |
| 39 | +- Confirmation of compliance with documentation standards |
34 | 40 |
|
35 |
| -All contributions have to be reviewed by someone. |
| 41 | +#### 3. Review Process |
36 | 42 |
|
37 |
| -It could be that the contribution can be merged immediately by a maintainer. However, usually, a new Pull Request needs some improvements before it can be merged. Other contributors (or helper robots) might have feedback. If this is the case the reviewing maintainer will help you improve your documentation. |
| 43 | +Modifications may require revision based on technical feedback before acceptance. The designated maintainers will provide standardized guidance for necessary improvements. |
38 | 44 |
|
39 |
| -If your documentation has passed human review, it is merged. |
| 45 | +Contributions fulfilling all technical and formal requirements will be integrated into the main documentation. |
40 | 46 |
|
41 |
| -### 4. Celebrate |
| 47 | +#### 4. Acknowledgment of Contribution |
42 | 48 |
|
43 |
| -Your ideas have become an integral part of this project. You are the Open Source hero we need! |
| 49 | +Upon successful integration, contributors will be formally recognized for their technical input to this specification. |
44 | 50 |
|
45 |
| -In fact, feel free to open a PR to add your name to the [`AUTHORS`](AUTHORS.md) file and get eternal attribution. |
| 51 | +Contributors may submit a Pull Request to add their credentials to the [AUTHORS](AUTHORS.md) file for permanent attribution in accordance with project protocols. |
46 | 52 |
|
47 | 53 | ---
|
48 | 54 |
|
49 |
| -For more information on how to use and contribute to this project, please read the [`README`](README.md). |
| 55 | +For complete technical specifications and additional contribution guidelines, refer to the [README](README.md) documentation and [Contributing Rules Section](CONTRIBUTING-RULES.md). |
0 commit comments