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.

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

Merged
merged 3 commits into from
Oct 4, 2023
Merged

Conversation

s-makin
Copy link
Contributor

@s-makin s-makin commented Sep 28, 2023

Tidy up contributing docs

In preparation for Hacktoberfest, but also because this was needed,
made a first proper go at reorganising the contributor docs. 

- 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

- 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
Copy link
Member

@TheRealFalcon TheRealFalcon left a 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:

  1. 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.
  2. 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.
image
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.


docs.rst
For existing contributors
Copy link
Member

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.

* 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``.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Run unit tests and/or linting checks pass using ``tox``.
* Ensure unit tests and/or linting checks pass using ``tox``.

or

Suggested change
* Run unit tests and/or linting checks pass using ``tox``.
* Run unit tests and/or linting checks using ``tox``.


summit.rst
Transferring CLA Signatures from Launchpad to GitHub
Copy link
Member

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.

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
Copy link
Member

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.

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.
Copy link
Member

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.

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
Copy link
Member

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

@@ -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
Copy link
Member

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.

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
Copy link
Member

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/``
Copy link
Member

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/``
Copy link
Member

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.


- Click :guilabel:`Pull Request`.

- Fill out the pull request title, summarizing the change and a longer message
Copy link
Member

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.

Copy link
Contributor Author

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.

@TheRealFalcon
Copy link
Member

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
Copy link
Member

@TheRealFalcon TheRealFalcon Oct 2, 2023

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``
==================
Copy link
Collaborator

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've changed this instead to ellipsis to represent that the elements are subdirectories until /var/lib/cloud. The result looks like this:

image

Copy link
Collaborator

@blackboxsw blackboxsw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@blackboxsw blackboxsw dismissed TheRealFalcon’s stale review October 4, 2023 04:22

James applied his review comments to this branch. So, that is an "approve" in my book

@blackboxsw blackboxsw merged commit 271ec8b into canonical:main Oct 4, 2023
26 checks passed
@aciba90 aciba90 mentioned this pull request Oct 16, 2023
3 tasks
@s-makin s-makin deleted the docs-contributing branch August 30, 2024 13:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants