-
Notifications
You must be signed in to change notification settings - Fork 881
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.
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
Tidy up contributing docs #4469
Conversation
s-makin
commented
Sep 28, 2023
- Organise docs by: Overview - Code - Docs - Community - Split out some content into separate files to make it more obvious where to find the content - Simplify new contributor docs - Add docs_layout to mirror the dir_layout file - Make docs style guide separate - Move introduction to explanation and include front page link to help direct people to it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left some inline comments. Overall great content that'll be way more helpful to newcomers.
Is there a reason development/index.html
no longer renders the CONTRIBUTING doc in Github? I think the separation causes a few issues:
- If I'm coming into the docs via the Github CONTRIBUTING.[rst|md] (most people will), I saw the same headers/introduction and didn't immediately realize there was more content beneath the Github version. I think it's confusing having to find out where to pick up on the new page.
- It means the two sources will likely diverge over time, and I'm not sure that's desirable.
Also, I just now realized that the section headings on the left sidebar are pages in and of themselves.
E.g., Contributing overview
is a page unto itself and not just a a heading container for what's below it. That's usually not what I expect from dropdown menus and probably won't be obvious because clicking the arrows doesn't open the page. The headers in the non-development section are essentially a really simple (one or two sentence) overview with links to the rest of the pages, but this PR adds quite a lot of content to the new headers. Would it make more sense to include a separate Overview page at the top of the children, then add a link from the heading to that overview? That way, important information won't be hidden in these section headers.
doc/rtd/development/index.rst
Outdated
|
||
docs.rst | ||
For existing contributors |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first bullet under here is a first-time contributor activity and we'll want first time contributors to do everything listed. I'm nervous a first time contributor would be tempted to gloss over this section as they're not an 'existing' contributor. The subheadings could perhaps stand on their own.
doc/rtd/development/index.rst
Outdated
* Add or update any :ref:`unit tests<testing>` accordingly. | ||
* Add or update any :ref:`integration_tests` (if applicable). | ||
* Format code (using ``black`` and ``isort``) with ``tox -e do_format``. | ||
* Run unit tests and/or linting checks pass using ``tox``. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* Run unit tests and/or linting checks pass using ``tox``. | |
* Ensure unit tests and/or linting checks pass using ``tox``. |
or
* Run unit tests and/or linting checks pass using ``tox``. | |
* Run unit tests and/or linting checks using ``tox``. |
doc/rtd/development/index.rst
Outdated
|
||
summit.rst | ||
Transferring CLA Signatures from Launchpad to GitHub |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At this point, we have been on GitHub long enough that we can delete this section.
doc/rtd/development/find_issues.rst
Outdated
You can express your interest in an issue by posting a comment on it. You | ||
should only work on one open issue at a time to avoid overloading yourself. | ||
|
||
If you have not submitted a PR (or a draft/"work-in-progress" PR) within a few |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A week feels a bit more reasonable to me. I think we can allow a comment explaining their status too as that shows they are still engaged. The big thing we want to avoid is "I'm working on this" and then them ghosting.
doc/rtd/development/find_issues.rst
Outdated
the PR commit message will link the issue to your proposed fix. This is the | ||
``Fixes GH-0000`` line in the template PR commit message. | ||
|
||
We will only assign an issue if there is a PR in progress. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's drop this line. If there's a linked PR, other people will already know not to work on it. Realistically, we'll probably only assign the PR in Github if it's a contributor we already have a history with.
doc/rtd/development/code_review.rst
Outdated
will perform an initial review, and monitor the PR to ensure that | ||
the **Proposer** is receiving any assistance that they require. The | ||
**Committers** will perform this assignment on a daily basis. | ||
The assigned committer can delegate the code review of a PR to another reviewer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this needs to be explicitly stated
doc/rtd/development/dir_layout.rst
Outdated
@@ -3,7 +3,7 @@ | |||
Directory layout | |||
**************** | |||
|
|||
``Cloud-init``'s directory structure is somewhat different from a regular | |||
Cloud-init's directory structure is somewhat different from a regular |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should remove the directory listing listed immediately after this line. It is woefully out of date.
doc/rtd/development/style_docs.rst
Outdated
capitalised at the start of a sentence (e.g., ``Cloud-init``). | ||
- ``metadata``, ``datasource``: One word. | ||
- ``user data``, ``vendor data``: Two words, not to be combined or hyphenated. | ||
- **Cloud-init**: Always hyphenated, and follows sentence case, so only |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would leave this lowercase. The point of the bullet is that we generally don't want the name of the project capitalized.
============= | ||
|
||
|
||
``man/`` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Contains the Linux man pages for the binaries provided by cloud-init.
When the documentation is built locally using ``tox -e doc``, the built pages | ||
can be found in this folder. | ||
|
||
``sources/`` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is...uh...weird. It contains an example project of how to use some particular functionality (OVF) within cloud-init. I'm guessing the original intention was to keep such demos here, but I didn't know this existed and not really sure it belongs here. We should probably document it as is until we move it though.
doc/rtd/development/first_PR.rst
Outdated
|
||
- Click :guilabel:`Pull Request`. | ||
|
||
- Fill out the pull request title, summarizing the change and a longer message |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hrm...I thought I had included a comment here earlier.
Since we have a PR template that is automatically populated anytime somebody creates a pull request, I'm not sure we need this template here too. The two have already diverged. We can instead say that when submitting a PR to fill out all pre-populated fields accordingly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I did wonder about that, but since this looked more like an example I didn't want to just remove it. Happy to take it out though for ongoing maintenance reasons.
I pushed a commit with my changes (not including the larger heading ones I mentioned). @blackboxsw wanna review too? Since I already reviewed, we probably don't need a super deep review here. |
@@ -0,0 +1,81 @@ | |||
Submit your first pull request |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I decided to remove quite a lot from this file and instead point the GitHub quickstart guide. Let me know if you think that was a mistake.
Original details were in the old contributing.rst.
``/var/lib/cloud`` | ||
================== |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In dropping the top directory tree, we now have slightly confusing rendering of the subdirectories as headings equal to the font and weight of the parent /var/lib/cloud. Let's make them subheadings so they are deemphasized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bbb08b4
to
03b3337
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
James applied his review comments to this branch. So, that is an "approve" in my book