Skip to content

Commit eab95bb

Browse files
authored
maintainer_guidelines: update (ansible#2632)
1 parent cda1b87 commit eab95bb

File tree

1 file changed

+67
-113
lines changed

1 file changed

+67
-113
lines changed

docs/docsite/rst/community/maintainers_guidelines.rst

Lines changed: 67 additions & 113 deletions
Original file line numberDiff line numberDiff line change
@@ -3,159 +3,113 @@
33
Maintainer responsibilities
44
===========================
55

6+
This document is intended for:
7+
8+
* Contributors to collections who are interested in joining their maintainer teams.
9+
* Collection maintainers who want to learn more about the subject.
10+
11+
This document explains what a collection maintainer is, outlines their responsibilities, and describes the process for becoming one.
12+
613
.. contents::
714
:depth: 1
815
:local:
916

10-
An Ansible collection maintainer is a contributor trusted by the community who makes significant and regular contributions to the project and who has shown themselves as a specialist in the related area.
11-
Collection maintainers have :ref:`extended permissions<collection_maintainers>` in the collection scope.
17+
Collection maintainer definition
18+
--------------------------------
1219

13-
Ansible collection maintainers provide feedback, responses, or actions on pull requests or issues to the collection(s) they maintain in a reasonably timely manner. They can also update the contributor guidelines for that collection, in collaboration with the Ansible community team and the other maintainers of that collection.
20+
An Ansible collection maintainer (or maintainer for short) is a contributor who:
1421

15-
In general, collection maintainers:
22+
* Makes significant and regular contributions to the project.
23+
* Has shown themselves as a specialist in the area the collection automates.
24+
* Trusted by the community: to be able to perform their duties, maintainers have the ``write`` or higher access level in the collection.
1625

17-
- Act in accordance with the :ref:`code_of_conduct`.
18-
- Subscribe to the collection repository they maintain (click :guilabel:`Watch > All activity` in GitHub).
19-
- Keep README, development guidelines, and other general collections :ref:`maintainer_documentation` relevant.
20-
- Review and commit changes made by other contributors.
21-
- :ref:`Backport <Backporting>` changes to stable branches.
22-
- Address or assign issues to appropriate contributors.
23-
- :ref:`Release collections <Releasing>`.
24-
- Ensure that collections adhere to the :ref:`collections_requirements`.
25-
- Track changes announced in `News for collection contributors and maintainers <https://github.com/ansible-collections/news-for-maintainers>`_ and update a collection in accordance with these changes.
26-
- Subscribe and submit news to the `Bullhorn newsletter <https://forum.ansible.com/c/news/bullhorn/17>`_.
27-
- :ref:`Build a healthy community <expanding_community>` to increase the number of active contributors and maintainers around collections.
28-
- Revise these guidelines to improve the maintainer experience for yourself and others.
29-
30-
Multiple maintainers can divide responsibilities among each other.
31-
32-
How to become a maintainer
33-
--------------------------
26+
Maintainer responsibilities
27+
---------------------------
3428

35-
A person interested in becoming a maintainer and satisfying the :ref:`requirements<maintainer_requirements>` may either self-nominate or be nominated by another maintainer.
29+
Collection maintainers:
3630

37-
To nominate a candidate, create a GitHub issue in the relevant collection repository. If there is no response, the repository is not actively maintained, or the current maintainers do not have permissions to add the candidate, Create a topic in the `Ansible community forum <https://forum.ansible.com/>`_.
31+
* Act in accordance with the :ref:`code_of_conduct`.
32+
* Subscribe to the repository they maintain (click :guilabel:`Watch > All activity` in GitHub).
33+
* Keep README, development guidelines, and other general :ref:`maintainer_documentation` relevant.
34+
* Review using the :ref:`review_checklist` and commit changes made by other contributors.
35+
* :ref:`Backport <Backporting>` changes to stable branches.
36+
* :ref:`Plan and perform releases <Releasing>`.
37+
* Ensure that the collection adhere to the :ref:`collections_requirements`.
38+
* Track changes announced through the `news-for-maintainers <https://forum.ansible.com/tag/news-for-maintainers>`_ forum tag (click the ``Bell`` button) and update the collection accordingly.
39+
* :ref:`Build a healthy community <expanding_community>` to increase the number of active contributors and maintainers around collections.
3840

39-
Communicating as a collection maintainer
40-
-----------------------------------------
41+
Multiple maintainers can divide responsibilities among each other.
4142

42-
Maintainers are highly encouraged to subscribe to the `"Changes impacting collection contributors and maintainers" GitHub repo <https://github.com/ansible-collections/news-for-maintainers>`_ and the `Bullhorn newsletter <https://forum.ansible.com/c/news/bullhorn/17>`_. If you have something important to announce through the newsletter (for example, recent releases), see the Bullhorn to learn how.
43+
Becoming a maintainer
44+
---------------------
4345

46+
If you are interested in becoming a maintainer and satisfy the :ref:`requirements<maintainer_requirements>`, please nominate yourself. You can also nominate another person:
4447

45-
Collection contributors and maintainers can also communicate through:
48+
1. Create a GitHub issue in the relevant repository.
49+
2. If there is no response, message the `Red Hat Ansible Community Engineering Team <https://forum.ansible.com/g/CommunityEngTeam>`_ on the `Ansible forum <https://forum.ansible.com/>`_.
4650

47-
* Real-time chats and forum topics appropriate to their collection, or if none exists, the general community and developer chat channels.
48-
* Collection project boards, issues, and GitHub discussions in corresponding repositories.
49-
* Contributor Summits and Ansible community days.
50-
* Ansiblefest and local meetups.
51+
Communicating as a maintainer
52+
-----------------------------
5153

52-
See :ref:`communication` for more details on these communication channels.
54+
Maintainers communicate with the community through channels listed in the :ref:`Ansible communication guide<communication>`.
5355

5456
.. _wg_and_real_time_chat:
5557

5658
Establishing working group communication
5759
----------------------------------------
5860

5961
Working groups depend on efficient communication.
60-
Project maintainers can use the following techniques to establish communication for working groups:
62+
As a maintainer, you can use the following techniques to establish communication for your working groups:
6163

62-
* Find an existing `forum group <https://forum.ansible.com/g>`_ or :ref:`working group<working_group_list>` that is similar to your project and join the conversation.
63-
* `Request <https://github.com/ansible/community/blob/main/WORKING-GROUPS.md>`_ a new working group for your project.
64-
* `Create <https://hackmd.io/@ansible-community/community-matrix-faq#How-do-I-create-a-public-community-room>`_ a public chat for your working group or `ask in the forum for help <https://forum.ansible.com/c/project/7>`_.
65-
* Provide working group details and links to chat rooms in the contributor section of your project ``README.md``.
66-
* Encourage contributors to join the forum group and chat.
64+
* Find an existing `forum group <https://forum.ansible.com/g>`_ and tags that suit your project and join the conversation.
65+
66+
* If nothing suits, `request them <https://forum.ansible.com/t/working-groups-things-you-can-ask-for/175>`_.
6767

68-
See the :ref:`Communication guide <communication_irc>` to learn more about real-time chat.
68+
* Provide working group details and links to chat rooms in the contributor section of your project ``README.md``.
69+
* Encourage contributors to join the forum group and appropriate tags.
6970

70-
Community Topics
71-
----------------
71+
Participating in community topics
72+
---------------------------------
7273

73-
The Community and the :ref:`Steering Committee <steering_responsibilities>` asynchronously discuss and vote on the :ref:`community topics<creating_community_topic>` which impact the whole project or its parts including collections and packaging.
74+
The Community and the :ref:`Steering Committee <steering_responsibilities>` asynchronously discuss and vote on the :ref:`community topics<creating_community_topic>`.
75+
The topics impact the whole project or its parts including collections and packaging.
7476

7577
Share your opinion and vote on the topics to help the community make the best decisions.
7678

7779
.. _expanding_community:
7880

79-
Contributor Summits
80-
-------------------
81-
82-
The quarterly Ansible Contributor Summit is a global event that provides our contributors a great opportunity to meet each other, communicate, share ideas, and see that there are other real people behind the messages on Matrix or Libera Chat IRC, or GitHub. This gives a sense of community. Watch the `Bullhorn newsletter <https://forum.ansible.com/c/news/bullhorn/17>`_ for information when the next contributor summit, invite contributors you know, and take part in the event together.
83-
84-
Weekly community Matrix/IRC meetings
85-
------------------------------------
86-
87-
The Community and the Steering Committee come together at weekly meetings in the ``#ansible-community`` `Libera.Chat IRC <https://docs.ansible.com/ansible/devel/community/communication.html#ansible-community-on-irc>`_ channel or in the bridged `#community:ansible.com <https://matrix.to/#/#community:ansible.com>`_ room on `Matrix <https://docs.ansible.com/ansible/devel/community/communication.html#ansible-community-on-matrix>`_ to discuss important project questions. Join us! Here is our `schedule <https://github.com/ansible-community/meetings/blob/main/README.md#schedule>`_.
88-
8981
Expanding the collection community
90-
===================================
91-
92-
.. note::
93-
94-
If you discover good ways to expand a community or make it more robust, edit this section with your ideas to share with other collection maintainers.
82+
==================================
9583

9684
Here are some ways you can expand the community around your collection:
9785

98-
* Give :ref:`newcomers a positive first experience <collection_new_contributors>`.
99-
* Invite contributors to join forum groups and :ref:`real-time chats <wg_and_real_time_chat>` related to your project.
100-
* Have :ref:`good documentation <maintainer_documentation>` with guidelines for new contributors.
101-
* Make people feel welcome personally and individually.
102-
* Use labels to show easy fixes and leave non-critical easy fixes to newcomers and offer to mentor them.
103-
* Be responsive in issues, PRs and other communication.
104-
* Conduct PR days regularly.
105-
* Maintain a zero-tolerance policy towards behavior violating the :ref:`code_of_conduct`.
106-
* Put information about how people can register code of conduct violations in your ``README`` and ``CONTRIBUTING`` files.
107-
* Include quick ways contributors can help and other documentation in your ``README``.
108-
* Add and keep updated the ``CONTRIBUTORS`` and ``MAINTAINERS`` files.
109-
* Create a pinned issue to announce that the collection welcomes new maintainers and contributors.
110-
* Look for new maintainers among active contributors.
111-
* Announce that your collection welcomes new maintainers.
112-
* Take part and congratulate new maintainers in Contributor Summits.
113-
114-
115-
.. _collection_new_contributors:
116-
117-
Encouraging new contributors
118-
-----------------------------
119-
120-
Easy-fix items are the best way to attract and mentor new contributors. You should triage incoming issues to mark them with labels such as ``easyfix``, ``waiting_on_contributor``, and ``docs``. where appropriate. Do not fix these trivial non-critical bugs yourself. Instead, mentor a person who wants to contribute.
121-
122-
For some easy-fix issues, you could ask the issue reporter whether they want to fix the issue themselves providing the link to a quick start guide for creating PRs.
123-
124-
Conduct pull request days regularly. You could plan PR days, for example, on the last Friday of every month when you and other maintainers go through all open issues and pull requests focusing on old ones, asking people if you can help, and so on. If there are pull requests that look abandoned (for example, there has been no response on your help offers since the previous PR day), announce that anyone else interested can complete the pull request.
86+
* Have it explicitly in your ``README`` that the collection welcomes new maintainers and contributors.
87+
* Give :ref:`newcomers a positive first experience <collection_new_contributors>`.
88+
* Invite contributors to join forum groups/subscribe to tags related to your project.
89+
* Have :ref:`good documentation <maintainer_documentation>` with guidelines for new contributors.
90+
* Make people feel welcome personally and individually. Greet and thanks them.
91+
* Use labels to show easy fixes and leave non-critical easy fixes to newcomers.
92+
* Offer help explicitly.
93+
* Include quick ways contributors can help and contributor documentation references in your ``README``.
94+
* Be responsive in issues, pull requests (or PRs for short) and other communication channels.
95+
* Conduct PR days regularly.
96+
* Maintain a zero-tolerance policy towards behavior violating the :ref:`code_of_conduct`.
12597

126-
Promote active contributors satisfying :ref:`requirements<maintainer_requirements>` to maintainers. Revise contributors' activity regularly.
127-
128-
If your collection found new maintainers, announce that fact in the `Bullhorn newsletter <https://forum.ansible.com/c/news/bullhorn/17>`_ and during the next Contributor Summit congratulating and thanking them for the work done. You can mention all the people promoted since the previous summit. Remember to invite the other maintainers to the Summit in advance.
129-
130-
Some other general guidelines to encourage contributors:
131-
132-
* Welcome the author and thank them for the issue or pull request.
133-
* If there is a non-crucial easy-fix bug reported, politely ask the author to fix it themselves providing a link to :ref:`collection_quickstart`.
134-
* When suggesting changes, try to use questions, not statements.
135-
* When suggesting mandatory changes, do it as politely as possible providing documentation references.
136-
* If your suggestion is optional or a matter of personal preference, please say it explicitly.
137-
* When asking for adding tests or for complex code refactoring, say that the author is welcome to ask for clarifications and help if they need it.
138-
* If somebody suggests a good idea, mention it or put a thumbs up.
139-
* After merging, thank the author and reviewers for their time and effort.
98+
* Put information about how people can register code of conduct violations in your ``README`` and ``CONTRIBUTING`` files.
14099

141-
See the :ref:`review_checklist` for a list of items to check before you merge a PR.
100+
* Look for new maintainers among active contributors.
142101

143102
.. _maintainer_documentation:
144103

145104
Maintaining good collection documentation
146-
==========================================
147-
148-
Maintainers look after the collection documentation to ensure it matches the :ref:`style_guide`. This includes keeping the following documents accurate and updated regularly:
149-
150-
* Collection module and plugin documentation that adheres to the :ref:`Ansible documentation format <module_documenting>`.
151-
* Collection user guides that follow the :ref:`Collection documentation format <collections_doc_dir>`.
152-
* Repository files that includes at least a ``README`` and ``CONTRIBUTING`` file.
153-
154-
A good ``README`` includes a description of the collection, a link to the :ref:`code_of_conduct`, and details on how to contribute or a pointer to the ``CONTRIBUTING`` file. If your collection is a part of Ansible (shipped with Ansible package), highlight that fact at the top of the collection's ``README``.
155-
156-
The ``CONTRIBUTING`` file includes all the details or links to the details on how a new or continuing contributor can contribute to this collection. The ``CONTRIBUTING`` file should include:
105+
=========================================
157106

158-
* Information or links to new contributor guidelines, such as a quick start on opening PRs.
159-
* Information or links to contributor requirements, such as unit and integration test requirements.
107+
Look after the collection documentation to ensure:
160108

161-
You can optionally include a ``CONTRIBUTORS`` and ``MAINTAINERS`` file to list the collection contributors and maintainers.
109+
* It is up-to-date.
110+
* It matches the :ref:`style_guide`.
111+
* Collection module and plugin documentation adheres to the :ref:`Ansible documentation format <module_documenting>`.
112+
* Collection user guides follow the :ref:`Collection documentation format <collections_doc_dir>`.
113+
* Repository files include at least a ``README`` and ``CONTRIBUTING`` file.
114+
* The ``README`` file contains all sections from `collection_template/README.md <https://github.com/ansible-collections/collection_template/blob/main/README.md>`_.
115+
* The ``CONTRIBUTING`` file includes all the details or links to the details on how a new or continuing contributor can contribute to your collection.

0 commit comments

Comments
 (0)