You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/community/project-management.md
+6-52
Original file line number
Diff line number
Diff line change
@@ -13,55 +13,13 @@ The aim is to ensure that the project has a high
13
13
14
14
## Maintenance team
15
15
16
-
We have a quarterly maintenance cycle where new members may join the maintenance team. We currently cap the size of the team at 5 members, and may encourage folks to step out of the team for a cycle to allow new members to participate.
16
+
[Participating actively in the REST framework project](contributing.md)**does not require being part of the maintenance team**. Almost every important part of issue triage and project improvement can be actively worked on regardless of your collaborator status on the repository.
17
17
18
-
#### Current team
18
+
#### Composition
19
19
20
-
The [maintenance team for Q4 2015](https://github.com/encode/django-rest-framework/issues/2190):
20
+
The composition of the maintenance team is handled by [@tomchristie](https://github.com/encode/). Team members will be added as collaborators to the repository.
Each maintenance cycle is initiated by an issue being opened with the `Process` label.
31
-
32
-
* To be considered for a maintainer role simply comment against the issue.
33
-
* Existing members must explicitly opt-in to the next cycle by check-marking their name.
34
-
* The final decision on the incoming team will be made by `@tomchristie`.
35
-
36
-
Members of the maintenance team will be added as collaborators to the repository.
37
-
38
-
The following template should be used for the description of the issue, and serves as the formal process for selecting the team.
39
-
40
-
This issue is for determining the maintenance team for the *** period.
41
-
42
-
Please see the [Project management](https://www.django-rest-framework.org/topics/project-management/) section of our documentation for more details.
43
-
44
-
---
45
-
46
-
#### Renewing existing members.
47
-
48
-
The following people are the current maintenance team. Please checkmark your name if you wish to continue to have write permission on the repository for the *** period.
49
-
50
-
- [ ] @***
51
-
- [ ] @***
52
-
- [ ] @***
53
-
- [ ] @***
54
-
- [ ] @***
55
-
56
-
---
57
-
58
-
#### New members.
59
-
60
-
If you wish to be considered for this or a future date, please comment against this or subsequent issues.
61
-
62
-
To modify this process for future maintenance cycles make a pull request to the [project management](https://www.django-rest-framework.org/topics/project-management/) documentation.
63
-
64
-
#### Responsibilities of team members
22
+
#### Responsibilities
65
23
66
24
Team members have the following responsibilities.
67
25
@@ -78,16 +36,12 @@ Further notes for maintainers:
78
36
* Each issue/pull request should have exactly one label once triaged.
79
37
* Search for un-triaged issues with [is:open no:label][un-triaged].
80
38
81
-
It should be noted that participating actively in the REST framework project clearly **does not require being part of the maintenance team**. Almost every import part of issue triage and project improvement can be actively worked on regardless of your collaborator status on the repository.
82
-
83
39
---
84
40
85
41
## Release process
86
42
87
-
The release manager is selected on every quarterly maintenance cycle.
88
-
89
-
* The manager should be selected by `@tomchristie`.
90
-
* The manager will then have the maintainer role added to PyPI package.
43
+
* The release manager is selected by `@tomchristie`.
44
+
* The release manager will then have the maintainer role added to PyPI package.
91
45
* The previous manager will then have the maintainer role removed from the PyPI package.
92
46
93
47
Our PyPI releases will be handled by either the current release manager, or by `@tomchristie`. Every release should have an open issue tagged with the `Release` label and marked against the appropriate milestone.
0 commit comments