Skip to content
GitLab
Projects
Groups
Snippets
/
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Menu
Open sidebar
tails
tails
Commits
7be29798
Commit
7be29798
authored
Apr 04, 2020
by
intrigeri
Browse files
GitLab: update terminology
parent
5bf480a2
Changes
4
Hide whitespace changes
Inline
Side-by-side
wiki/src/contribute/working_together/GitLab.mdwn
View file @
7be29798
...
...
@@ -114,8 +114,8 @@ met:
- The task is both important and urgent.
- The
_Target versi
on
_
is set to the next Tails release.
See the
"Target version"
section
above
for details.
- The
milest
on
e
is set to the next Tails release.
See the
[[milestone|GitLab#milestone]]
section for details.
- We did all the work we could on this task already and now have to
track progress on a blocker that we cannot address ourselves.
...
...
@@ -142,14 +142,14 @@ Different teams and contributors use the _Milestone_ value differently:
contributors should be able to rely on.
- Others use it as a pool of tasks they want to have on their short-term radar.
For issues that are on the Tails [[!tails_roadmap]], the
_Target versi
on
_
is set
For issues that are on the Tails [[!tails_roadmap]], the
milest
on
e
is set
to a year, until it makes sense to target a specific release.
Postponing to the next
_Target versi
on
_
more than once is not business
Postponing to the next
milest
on
e
more than once is not business
as usual — it's a red flag. Ideally, the underlying problem should be identified
and addressed: for example, the assignee might need help or be over-committed;
the team could be under-staffed; or perhaps the task should simply not have
a
_Target versi
on
_
in the first place.
a
ny milest
on
e
in the first place.
## Priority
...
...
wiki/src/contribute/working_together/roles/foundations_team.mdwn
View file @
7be29798
...
...
@@ -134,7 +134,7 @@ An issue
[[
!tails_gitlab
groups
/
tails
/-/
issues
?
label_name
%
5
B
%
5
D
=
Core
+
Work
%
3
AFoundations
+
Team
desc
=
"owned by the Foundations Team"
]]
should
have
the
_Target
version_
field
set
if
,
and
only
if
,
at
least
should
have
a
milestone
set
if
,
and
only
if
,
at
least
one
of
these
conditions
is
met
:
-
External
constraints
determine
the
timeline
of
our
work
.
...
...
@@ -147,15 +147,15 @@ one of these conditions is met:
as
opposed
to
starting
work
on
a
new
task
.
-
The
task
is
on
the
Tails
[[
!tails_roadmap]]. In this case, the
_Target
versi
on
_
should
be
a
year
,
unless
one
of
the
above
milest
on
e
should
be
a
year
,
unless
one
of
the
above
conditions
makes
us
target
a
specific
release
.
Postponing
a
task
to
the
next
_Target
versi
on
_
more
than
once
is
not
Postponing
a
task
to
the
next
milest
on
e
more
than
once
is
not
business
as
usual
—
it
's a red flag. Such a change should be
justified. The underlying problem should be identified and addressed:
for example, the assignee might need help or be over-committed; the
team could be under-staffed; or perhaps the task should simply not
have a
_Target versi
on
_
in the first place.
have a
ny milest
on
e
in the first place.
<a id="tasks-management-assignee"></a>
...
...
wiki/src/contribute/working_together/roles/sponsor_deliverables/team_manager.mdwn
View file @
7be29798
...
...
@@ -17,7 +17,7 @@ While working on a deliverable
==============================
- Ensure that the workers on your team actually do the work on time.
Help them as needed in whatever way you see fit, e.g. create
ticket
s,
Help them as needed in whatever way you see fit, e.g. create
issue
s,
organize meetings, organize feedback sessions.
- Regularly check the status of work vs. deadlines.
...
...
wiki/src/contribute/working_together/roles/sponsor_deliverables/worker.mdwn
View file @
7be29798
...
...
@@ -6,16 +6,16 @@ a sponsor, you must:
- Ask any information you lack to your
[[sponsor_deliverables/team_manager]].
- Track which
ticket
corresponds to which deliverable.
- Track which
issue
corresponds to which deliverable.
Ensure each of your deliverables has a
ticket in Redmine
with the
correct _Deliverable for_
value
.
Ensure each of your deliverables has a
n issue in GitLab
with the
correct _Deliverable for_
label
.
- Schedule your work in advance to meet deadlines:
- Plan for surprises such as tasks that are unexpectedly harder
than planned.
- Use the
_Target versi
on
_
field in
Redmine
to track your own plans
- Use the
milest
on
e
field in
GitLab
to track your own plans
and timing goals. Keep this information up-to-date at all times.
- Check how good you're doing wrt. their deliverables and deadlines.
...
...
@@ -24,13 +24,13 @@ a sponsor, you must:
- Report your progress on deliverables when requested.
Summarize the
ticket
s and achievements of each deliverables since
Summarize the
issue
s and achievements of each deliverables since
the last report. This information will then be transmitted to the
Accounting Team for invoicing. Clarify the matching between
ticket
s
Accounting Team for invoicing. Clarify the matching between
issue
s
and deliverables; for example, you can report:
- "B.3.7 completed: #nnnn, #mmmm, etc.": all these
ticket
s must
have the _Resolved_ status in Redmine
.
- "B.3.7 completed: #nnnn, #mmmm, etc.": all these
issue
s must
be closed in GitLab
.
- "C.4.2 (#nnnn, #mmmm) in progress but not completed because of
$reasons".
...
...
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment