Added first draft of the implementation scheme.
Robert Zenz
parent
b88d2f5374
commit
1711a5ca41
|
|
@ -0,0 +1,102 @@
|
|||
Implementation
|
||||
==============
|
||||
|
||||
|
||||
0. Purpose of this document
|
||||
---------------------------
|
||||
|
||||
The purpose of this document is to outline the scheme necessary to implement
|
||||
the changes outlined in the previous documents.
|
||||
|
||||
|
||||
1. Changes to the repository
|
||||
----------------------------
|
||||
|
||||
The changes in the repository are the easiest to do, the new tags, the teams
|
||||
and the milestones must be created.
|
||||
|
||||
|
||||
2. Issues
|
||||
---------
|
||||
|
||||
The first, and most likely easiest task is to tackle the issues.
|
||||
|
||||
Each and every issue must be looked at, the developers must be added and, where
|
||||
appropriate, milestones must be set. This can be done by a single developer but
|
||||
all other developers should work through the generated lists of issues which
|
||||
they are now assigned to them:
|
||||
|
||||
1. Is this issue still relevant (has it been fixed, is not applicable anymore)?
|
||||
2. Is this actually something we want?
|
||||
3. Is information missing?
|
||||
4. Does somebody else need to be added?
|
||||
5. Does it need different tags?
|
||||
6. Does it need a milestone?
|
||||
|
||||
After that all developers should actually have a good idea of what issues are
|
||||
in the tracker and what they are up against.
|
||||
|
||||
|
||||
3. Pull requests
|
||||
----------------
|
||||
|
||||
Now the big part are the pull requests.
|
||||
|
||||
Again, each and every pull request needs to be looked at, the new tags need to
|
||||
be added and people need to be assigned. After that the assigned developers must
|
||||
work through their lists:
|
||||
|
||||
1. Is the pull request still relevant?
|
||||
2. Is this something we want?
|
||||
3. What's the status, what is missing?
|
||||
4. Does somebody else need to be added?
|
||||
5. Does it need different tags?
|
||||
6. Does it need a milestone?
|
||||
|
||||
After that the pull requests need to be handled, plain and simple as that.
|
||||
|
||||
|
||||
4. Doing this regularly
|
||||
-----------------------
|
||||
|
||||
All this previously mentioned actions can only improve the situation if
|
||||
they are performed on a regular basis. Developers must work themselves through
|
||||
the list of their issues and pull requests and must check them.
|
||||
|
||||
Ideally the workload will drop off after the backlog has been dealed with, which
|
||||
might or might not take some time. After that the ideal case is that a developer
|
||||
only has a handful, if at all, pull requests which they must attend to.
|
||||
|
||||
The pull requests should be handled in this order:
|
||||
|
||||
1. Active/in progress pull requests should be handled first, as the contributor
|
||||
is most motivated in that stage and the momentum should be preserved.
|
||||
2. Older pull requests should be looked at again and checked, why are they
|
||||
still pending? Is input from the core developers missing? Are changes from
|
||||
the contributor missing? Those should be poked at a quite regular basis.
|
||||
3. New pull requests should be handled.
|
||||
|
||||
Even though new pull requests are quite important, they can be handled last,
|
||||
as the contributor is already prepared that the initial handling might take some
|
||||
time. On the other hand a pull request which is dragging on and on has
|
||||
the potential of losing the contributor, especially if the contributor is
|
||||
constantly waiting on input from the team.
|
||||
|
||||
|
||||
5. Conclusion
|
||||
-------------
|
||||
|
||||
The current state of the project has accumulated over years and is a result of
|
||||
many factors. The only way to change that is through, some quite hard, work, and
|
||||
the most important part is that the issues and pull requests need constant
|
||||
attention. Once the backlog of pull requests has been dealt with, the required
|
||||
amount of work will drop off like a cliff, but it will also require constant
|
||||
work to make sure that such a backlog does never accumulate again.
|
||||
|
||||
Theoretically, some of these tasks don't require core developers to do them, for
|
||||
example the initial tagging and assigning and the merging. These could be done,
|
||||
additionally to the core developers, by another team which lacks the power to
|
||||
approve pull requests but is otherwise allowed to merge and change them. This
|
||||
would allow to split the work required and might actually improve the reaction
|
||||
time on pull requests.
|
||||
|
||||
Loading…
Reference in New Issue