Commit 2196f3fc authored by intrigeri's avatar intrigeri
Browse files

GitLab: deduplicate

The "Assignee" section now sets up a workflow that attacks the over-commitment,
cookie-licking, and unclear-ETA problems at the root. In this workflow, issues
being left unassigned becomes the norm, rather than a problem to solve.

So I'm rephrasing the "Report progress or failure" section in a way that builds
upon this, and refers to it, while it was previously (implicitly) phrased in
a context when we would assign as many issues as we could, ahead of time.
parent 015a2e53
...@@ -255,13 +255,16 @@ commit on the corresponding issue, once the branch is pushed to our ...@@ -255,13 +255,16 @@ commit on the corresponding issue, once the branch is pushed to our
## Report progress or failure ## Report progress or failure
It is important for the team to know whether somebody is feeling responsible to It is important to:
make a task happen, or that it's a wishlist/patches-welcome/don't-care-that-much
(would be great, but *We* don't feel committed to make it happen any time soon).
Thus, it is great to state if you'd like to do it, but also to state if you - Keep the team informed of how you feel committed to issues assigned to you,
won't do it anymore. Don't feel guilty: it's better if we all know it won't happen and about the timeline you're envisioning.
soon rather than you feel pressured while having other priorities! - Avoid individual over-commitment & feelings of failure.
If you don't think you will manage to work on an issue any time soon,
it's often best to make this clear on the issue, or to de-assign yourself.
For details, see how we use the [[assignee|GitLab#assignee]] information.
# How to request and provide input # How to request and provide input
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment