15072028c4
This change replaces direct links to GitHub master branch with auto-generated links using docutils custom roles. These auto-generated links point to the tree or blob for the git commit ID (or tag) of the repository. This is needed to ensure that links don’t become broken when files in master branch are moved around or deleted. The following roles are introduced: - :idf:`path` - points to directory inside ESP-IDF - :idf_blob:`path` - points to file inside ESP-IDF - :idf_raw:`path` - points to raw view of the file inside ESP-IDF - :component:`path` - points to directory inside ESP-IDF components dir - :component_blob:`path` - points to file inside ESP-IDF components dir - :component_raw:`path` - points to raw view of the file inside ESP-IDF components dir - :example:`path` - points to directory inside ESP-IDF examples dir - :example_blob:`path` - points to file inside ESP-IDF examples dir - :example_raw:`path` - points to raw view of the file inside ESP-IDF examples dir A check is added to the CI build script, which searches RST files for presence of hard-coded links (identified by tree/master, blob/master, or raw/master part of the URL). This check can be run manually: cd docs && make gh-linkcheck Additionally, Sphinx linkcheck build type is used to create new CI test, which check for broken links. This test has to be triggered explicitly, because including it in normal build process (when the commit is not yet deployed to Github) will not work. It can be triggered in a regular fashion using a combination of cron and Curl, similar to stress tests.
47 lines
2.1 KiB
ReStructuredText
47 lines
2.1 KiB
ReStructuredText
Contributions Guide
|
|
===================
|
|
|
|
We welcome contributions to the esp-idf project!
|
|
|
|
How to Contribute
|
|
-----------------
|
|
|
|
Contributions to esp-idf - fixing bugs, adding features, adding documentation - are welcome. We accept contributions via `Github Pull Requests <https://help.github.com/articles/about-pull-requests/>`_.
|
|
|
|
Before Contributing
|
|
-------------------
|
|
|
|
Before sending us a Pull Request, please consider this list of points:
|
|
|
|
* Is the contribution entirely your own work, or already licensed under an Apache License 2.0 compatible Open Source License? If not then we unfortunately cannot accept it.
|
|
|
|
* Does any new code conform to the esp-idf :doc:`Style Guide <style-guide>`?
|
|
|
|
* Does the code documentation follow requirements in :doc:`documenting-code`?
|
|
|
|
* Is the code adequately commented for people to understand how it is structured?
|
|
|
|
* Is there documentation or examples that go with code contributions? There are additional suggestions for writing good examples in :idf:`examples` readme.
|
|
|
|
* Are comments and documentation written in clear English, with no spelling or grammar errors?
|
|
|
|
* If the contribution contains multiple commits, are they grouped together into logical changes (one major change per pull request)? Are any commits with names like "fixed typo" `squashed into previous commits <http://eli.thegreenplace.net/2014/02/19/squashing-github-pull-requests-into-a-single-commit/>`_?
|
|
|
|
* If you're unsure about any of these points, please open the Pull Request anyhow and then ask us for feedback.
|
|
|
|
Pull Request Process
|
|
--------------------
|
|
|
|
After you open the Pull Request, there will probably be some discussion in the comments field of the request itself.
|
|
|
|
Once the Pull Request is ready to merge, it will first be merged into our internal git system for in-house automated testing.
|
|
|
|
If this process passes, it will be merged onto the public github repository.
|
|
|
|
Legal Part
|
|
----------
|
|
|
|
Before a contribution can be accepted, you will need to sign our :doc:`contributor-agreement`. You will be prompted for this automatically as part of the Pull Request process.
|
|
|
|
|
|
|