Commit 62f3541a authored by intrigeri's avatar intrigeri

Start migrating contributors doc to GitLab (tails-team/gitlab-migration#30)

parent 373a9dea
......@@ -27,7 +27,7 @@ Most of the possible candidate goals that were
critical. Pursuing these would require substantial effort, that is
better put into other Tails improvements. Therefore, they have not
made their way into our [[!tails_roadmap]]. Some have low-priority
tickets on [[!tails_redmine desc="Redmine"]], meaning that patches are
tickets on [[!tails_gitlab desc="GitLab"]], meaning that patches are
welcome, but we do not feel committed, as a project, to make
it happen.
......@@ -3,7 +3,7 @@
See also:
* the [[corresponding design document|contribute/design/incremental_upgrades]];
* the tickets with the _Incremental upgrades_ category on [[!tails_redmine "" desc="Redmine"]].
* the tickets with the _C: Upgrader_ label on [[!tails_gitlab "" desc="GitLab"]].
# Random ideas for future improvements
[[!meta title="Bugs"]]
If you've found a bug in Tails, please read [[doc/first_steps/bug_reporting]].
We don't use this section anymore, see [[contribute/working_together/Redmine]] instead.
......@@ -132,10 +132,8 @@ Tools for contributors
- Source code: [[Git repositories|contribute/git]]
- [[!tails_roadmap desc="Roadmap"]]
- [[Redmine bug tracker|contribute/working_together/Redmine]]
- [[Starter tasks|starter_tasks]] for new contributors
- [Tasks](
can be filtered by type of work (see links in the sidebar)
- [[GitLab|contribute/working_together/GitLab]]
- [[Starter tasks|starter_tasks]] for new contributors
- [[Building a Tails image|contribute/build]]
- [[Build a local copy of the website|contribute/build/website]]
- [[Customize Tails|contribute/customize]]
......@@ -157,7 +155,7 @@ you might need some guidance.
Here is a list of mentors who can help with
specific tasks. Feel free to talk to them if you plan to work on anything related to their
field of expertise, for example
by assigning them tickets on Redmine or <a href="#talk">talking to us</a>
by assigning them issues on GitLab or <a href="#talk">talking to us</a>
using the usual communication channels.
- AppArmor: intrigeri, jvoisin, u
......@@ -796,7 +796,7 @@ through the necessary steps.
## 3.5 Feedback
Users can send feedback in several ways to Tails developers.
A [[!tails_redmine desc="task tracker"]] is available.
A [[!tails_gitlab desc="task tracker"]] is available.
Users can also send email to the private [[developers mailing
list|about/contact#tails]] or to the private [[support mailing
......@@ -57,7 +57,7 @@ upstream... which sometimes implies to write a patch ourselves.
## Pick up a task
We use [[!tails_redmine "" desc="Redmine"]] to manage
We use [[!tails_gitlab "" desc="GitLab"]] to track
our lists of tasks and bugs, as well as our [[!tails_roadmap]].
If you already know which one of the listed tasks you want to tackle
and it has the *Code* Type of work, then you can probably
......@@ -103,8 +103,8 @@ So you know what bug you want to fix, what feature you want to
implement. At this point, we advise you to:
1. **Gather results of previous research and discussions** on the
topic you are interested in. Search this website, [[!tails_redmine ""
desc="tickets on Redmine"]] and the [ mailing list
topic you are interested in. Search this website, [[!tails_gitlab ""
desc="issues on GitLab"]] and the [ mailing list
2. **[[Tell us on|about/contact#tails-dev]] about your plans** to make sure your
idea fits nicely into the [[big picture|contribute/design]], and
......@@ -158,8 +158,6 @@ You can also:
* subscribe to this website's RSS feed (see [[recentchanges]]);
* track the Git commits (using [[our Gitweb|contribute/git]]'s RSS
* track [[review'n'merge
## Build a Tails ISO
......@@ -10,7 +10,7 @@ feature.
Tasks that are currently stalled by the need for input have the
the `Research`, `Discuss`, or `Test` *Type of work* on our
[[!tails_redmine "" desc="TODO"]] list.
[[!tails_gitlab "" desc="TODO"]] list.
You probably want to start looking at the ones that are also in the
[[!tails_redmine_starter]] first so that you can gain confidence...
and we can smoothly learn to work together.
This diff is collapsed.
Tails tasks are managed in a [[!tails_redmine "" desc="Redmine project"]].
If you need to do something in Redmine and you appear to lack the
needed credentials, please ask [[|about/contact#tails-sysadmins]] to give you
more power.
Some documentation about how we are using Redmine is available in the
[[contribute/working_together]] pages. See also the [[review and merge
process|contribute/merge_policy/review]] documentation.
Tinkering with Redmine is an important part of the
[[Ticket gardener|contribute/working_together/roles/ticket_gardener/]] role.
[[!toc levels=2]]
<a id="atom"></a>
Atom feeds
Each custom query listed in the Redmine sidebar has an Atom feed.
Tracking review'n'merge requests
Subscribe to:
* the [*Completed for the next release*](
* the [*Needs Validation*]( feed;
* merge requests on [Salsa](
How to use Redmine's Atom feeds
To use a Redmine Atom feed:
1. Go to the custom query you want to track.
2. Look for the *Atom* link at the bottom of the page.
3. Point your feed reader to that link.
Email commands
This only works by sending mails from an email address associated with
a Redmine account.
For details, see the [corresponding documentation on the Redmine
Creating a ticket by email
You need to provide all the required fields in the body of the email, and the
syntax is case sensitive. For example this works:
Subject: Test creating a ticket by email
Project: tails
Tracker: Feature
Status: Confirmed
Priority: Low
Type of work: Test
It should be possible to create a ticket by sending an email to Redmine.
If you send attachments with your email they will also be attached to the
ticket. For example your OpenPGP signature :)
Updating a ticket by email
An easy trick is to reply to an email notification about that ticket. Then only
include in the body of the email the fields that you want to change, and a
description for your changes. For example:
Subject: Re: [Tails - Feature #6813] (Confirmed) Test creating a ticket by email
Status: Resolved
This works but Redmine is quite picky on the syntax...
<a id="fields"></a>
How to use Redmine fields
It is important to be consistent in the use of the fields to make collective work
easier. See [[document progress|contribute/working_together/document_progress]]
for more on this topic.
Please take a time to see how we use the fields of Redmine:
* Subject:
- The Subject should be a short but clear description of what the ticket is about.
Some people are case sensitive, please try to consider that.
* Description:
- For the preferred style of this field when reporting a bug, refer to our
[[bug reporting instructions|doc/first_steps/bug_reporting]]. Features or
Discuss tickets may follow a different style.
* Status:
* New:
- New users' tickets are marked always as new. If a Tails contributor can
reproduce the issue, it should be marked as *Confirmed*.
- [[Help desk|contribute/working_together/roles/help_desk]] team is in
charge of keeping an eye on them.
* Confirmed:
- Tails contributors can reproduce the issue.
* In Progress:
- Some work towards resolution has been done.
- Added by Redmine automatically when a Git commit with `will-fix: #NNNN`
is added to the Tails repository. This keyword should be only used in
topic branches.
* Needs Validation
- Proposed changes are ready to be reviewed.
Read our [[merge policy|/contribute/merge_policy]] to know more.
* Resolved:
- Fixed in Git. The _Target version_ indicates whether it is fixed
in a version of Tails that was already released, or for a future one.
* Duplicate:
- Another ticket in Redmine covers this issue. Do not forget the related issue!
You can add a related issue from the 'Related issues' section on the ticket.
* Rejected:
- Not applicable, not a Tails problem, being worked on elsewhere.
* Priority
* Low:
- It would be good to have it, but nobody is volunteering to do it.
* Elevated:
- Regressions are always marked as Elevated.
* Assignee: assign yourself to a ticket if you are working on it to prevent duplicated
* Category:
- This are usually transversal issues, not specific tools.
* Target version:
- The Tails release this ticket aims to be fixed for.
- If submitting code, the Tails release you would like your changes to be in.
* Feature Branch:
- Add the information of the branch for this issue in the format
`repositoryname:branch`, or only the branch name if it's on Tails repository.
* Type of work:
* Communicate:
- Inside or outside of Tails (for example, with other projects).
* Contributors documentation:
- Everything below /contribute on the website.
* Debian:
- Related or to be done on the Debian project.
* Discuss:
- Discuss tickets are reviewed to discuss during the monthly Tails
contributors meeting.
* End-user documentation:
- Everything below /doc on the website.
* Wait:
- Used when waiting for input from other projects.
* Website:
- All website work not covered by other options.
* Watchers:
- If you think somebody might be interested on this ticket although not as
assignee, you can add them as a watcher. They will receive an email with
information every time the ticket gets updated.
- If you create a ticket you will receive updates like a watcher.
- If you comment on a ticket, you're *not* automatically a watcher.
* Parent task:
- It is always good to add it if there is any. Sometimes we use this field to
organize work that spans over many tickets. See for example: [[!tails_ticket 7584]].
* Blueprint:
- Many times the work to fix the tickets is also done in a wiki page, see
* Starter:
- Issues flagged as *Starter* on Redmine are a great tool for new contributors
getting into Tails. [[Learn
# Requesting input from someone else
If you want to work on a ticket but you need some input from someone
else, ask your question on a comment on the ticket, mentioning them
with their Redmine login name: `@nick`. Redmine will send them
an email notification about it.
If you expect the person you're asking input from will need to do
substantial amounts of work to answer your question, you may file
a dedicated subtask assigned to them.
# Acting upon input requests
It's important to provide requested information as quickly as you can,
to make the Tails contribution process more efficient and enjoyable.
When input is requested from you on a ticket with `@nick`, you get an
email notification. You should ensure your email setup allows you to
notice such email from Redmine.
When you receive such a request, if you cannot provide the requested
input immediately, you're responsible for keeping track of this task,
for example by creating a new subtask assigned to yourself, or using
whatever personal organization tools that work for you.
# Core team's work
Some of the teams who do
[[Core work|contribute/working_together/roles]] (be it paid or done on
a volunteer basis) maintain Redmine metadata in order to:
* provide visibility on what they doing & their priorities;
* give the Tails community some power over setting these priorities;
* allow the Tails community to help core workers define their
priorities: they sometimes have a hard time deciding by themselves
how they should spend their time on what matters the most to
the project.
In the [[!tails_redmine "" desc="Redmine"]] sidebar, you can see
a bunch of views whose name starts with *Core work*.
The teams who use this mechanism are more than happy to get feedback
about these priorities: both addition and removal suggestions are
welcome. Please check the mission statement for the corresponding team
first, to ensure you're not asking them to do something that's outside
of the scope of their job. And please justify your suggestions.
Please check these views once in a while and talk to us! :)
Tails issues are now tracked in [[working_together/GitLab]].
......@@ -24,7 +24,7 @@ General
- Not *Starter*:
- Has subtasks or is blocked by other issues.
- Is blocked by other issues.
- Needs to be split to be actionable.
Audit & Research
[[!meta title="Document progress"]]
# Create and update ticket
# Create and update issues
When a developer works on a task, she should create/update a ticket related to
When a developer works on a task, she should create/update a GitLab issue related to
the task. All the knowledge useful to the others should be kept there (or at
least linked from there). She should take care of updating this ticket's
[[properties|/contribute/working_together/Redmine#fields]] so that they reflect
least linked from there). She should take care of updating this issue's
[[metadata|/contribute/working_together/GitLab#metadata]] so that they reflect
the actual status of the task, and especially the next thing to do for it to be
The tickets are stored in [[!tails_redmine "" desc="Redmine"]].
The issues are stored in [[!tails_gitlab "" desc="GitLab"]].
When committing changes that will resolve a ticket once merged, please
consider including `will-fix: #NNNN` in the commit message, _NNNN_
being the ticket number. Then, Redmine will automatically flag the
corresponding ticket as "In Progress" once the branch is pushed to our
When committing changes that will resolve an issue once merged, please
include `#NNNN` in the commit message, _NNNN_
being the issue number. Then, GitLab will automatically reference this
commit on the corresponding issue, once the branch is pushed to our
main [[Git repository|contribute/Git]]. For example:
Remove duty from frontdesk (Will-fix: #8420)
Remove duty from frontdesk (#8420)
This keyword should be used only in topic branches, or when committing
directly in the master branch. When merging topic branches into
development branches, you should used the [[`Closes`|merge_policy#closes]] keyword
When you merge a topic branch into one of our main branches,
use the [[`Closes`|merge_policy#closes]] keyword instead.
# Report progress or failure
......@@ -33,9 +33,9 @@ The Tails Foundations Team is responsible for:
put it on our Technical Writers' plate, or draft something directly,
or merge a draft proposed by Technical Writer apprentices;
* handling new tickets when they are more technical than feature
* handling new issues when they are more technical than feature
request (those are handled by the UX designers) or about bugs;
reassigning to whoever is on Help Desk duty any new ticket that's
reassigning to whoever is on Help Desk duty any new issue that's
really a support request;
* ensuring that development discussions started on
......@@ -52,12 +52,11 @@ The Tails Foundations Team is responsible for:
- An emergency release is often needed shortly after [[!wikipedia Pwn2Own]].
* reviewing'n'merging proposed branches in a timely manner (1 week in
general, up to 2 weeks if needed in exceptional cases). If a ticket
is flagged *Needs Validation*, but nobody on the Foundations Team can
general, up to 2 weeks if needed in exceptional cases). If an issue
is labeled *3. Needs Validation*, but nobody on the Foundations Team can
take care of the review'n'merge, it's the Foundations Team's
responsibility to ask for help. These tickets can be tracked using:
responsibility to ask for help. These issues can be tracked using:
- the "Release Manager View: VERSION";
- the
[Needs Validation, with no assignee](
......@@ -105,7 +104,7 @@ Each month the Tails Foundations Team gathers for an online meeting.
As a Foundations Team member, if you cannot make one of these
meetings, please send the team before the meeting:
- a brief status update about life, work and tickets;
- a brief status update about life, work and issues;
- information about how much more or less work you want for the
following month(s).
......@@ -123,18 +122,19 @@ tasks](
This applies on top of the broader Tails project's tasks management
- [[contribute/working_together/Redmine]]
- [[contribute/working_together/GitLab]]
- [[contribute/working_together/document_progress]]
<a id="tasks-management-milestone"></a>
<a id="tasks-management-target-version"></a>
## Target version
## Milestone
The Foundation Team treats the _Target version_ field as a commitment.
The Foundation Team treats the _Milestone_ field as a commitment.
Other Tails teams, contributors, and users should be able to rely on
the value of this field.
A ticket [owned by the Foundations
An issue [owned by the Foundations
should have the _Target version_ field set if, and only if, at least
one of these conditions is met:
......@@ -163,68 +163,35 @@ have a _Target version_ in the first place.
## Assignee
We use the _Assignee_ field in a way that helps us organize share our
work as a team, focus on what matters most currently, and avoid
individual over-commitment & feelings of failure.
To this aim, most tasks should be up for grabs for anyone who has
spare capacity and the required skills: [Don't Lick the
A ticket [owned by the Foundations
should not be assigned to anyone in general. But we do assign a ticket
if at least one of these conditions is met:
- The task is both important and urgent.
- The _Target version_ is set to the next Tails release.
See the "Target version" section above 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.
For example, regularly tracking progress and pinging on patches
we've submitted upstream.
- Only one of us can complete the task. This helps identify
bottlenecks, high bus factor, and over-commitment.
- This task is the assignee's current top priority wrt. Tails work.
- Sponsor deliverables that are managed under the "let's decide
a long time in advance who exactly will do each task" paradigm.
- It is about the parent ticket for a large project with several
subtasks that will be tackled by different people, and we need
someone to coordinate the project.
See [[contribute/working_together/GitLab#assignee]].
<a id="tasks-management-ux-improvements"></a>
## UX improvements
Our [[UX designers|roles/ux]] maintain a list of UX improvements that
would be welcome, as tickets related to [[!tails_ticket 14544]].
would be welcome, as issues related to [[!tails_ticket 14544]].
From time to time, some Foundations Team members meet with UX
designers and do a value/cost analysis of these tickets. Then, those
designers and do a value/cost analysis of these issues. Then, those
with the best value/cost, that we can work on without waiting for lots
of UX design work to be done, are added to [our list of
That is, working on them automatically qualifies as Foundations Team work.
In general, before looking for other UX improvements we could work on,
we should first focus on these selected tickets and on the most
we should first focus on these selected issues and on the most
important or urgent of our other [[duties|foundations_team#duties]].
Still, while keeping this in mind, you might personally be
particularly interested in working on a ticket related to
particularly interested in working on an issue related to
[[!tails_ticket 14544]], that was not added to our plate yet.
It is an option to turn one such ticket into Foundations Team work,
It is an option to turn one such issue into Foundations Team work,
provided a few conditions are met.
The Foundations Team lead maintains a list of tickets that meet
The Foundations Team lead maintains a list of issues that meet
these conditions, in the description of [[!tails_ticket 14544]].
You can check yourself if a particular ticket meets all these
You can check yourself if a particular issue meets all these
- It was marked as related to [[!tails_ticket 14544]] by our UX designers.
......@@ -232,19 +199,19 @@ conditions:
- It is possible work on it without waiting for lots of UX work to be done first.
To determine whether that's the case:
- Look at the "UX" cost column in the spreadsheet attached to
[[!tails_ticket 14544]]. A ticket with a UX cost of 2 or more
[[!tails_ticket 14544]]. An issue with a UX cost of 2 or more
probably does not qualify.
- In doubt, ask our UX designers.
- The P×S/Cdev value is 1.0 or greater, in the spreadsheet that's
attached to [[!tails_ticket 14544]].
When you start working on such a ticket:
When you start working on such an issue:
- Assign it to yourself.
- Notify our [[UX designers|roles/ux]] with a `@sajolida` mention on
the ticket: then they can explain what kind of work they have to do
the issue: then they can explain what kind of work they have to do
before you can complete your part of the work.
<a id="contact"></a>
......@@ -115,7 +115,7 @@ Tails system administrators have write access to the puppetmasters, and can log
the hosts.
They read the <> encrypted mailing list.
We use [[!tails_redmine desc="Redmine"]] tickets for public discussion
We use [[!tails_gitlab desc="GitLab"]] tickets for public discussion
and tasks management:
* To bring a ticket to the attention of system administrators,
......@@ -111,7 +111,7 @@ Localization and Internationalization
- Our todo list items were [[!tails_redmine desc="migrated to Redmine"]].
- Our todo list items were migrated to Redmine.
- Blueprints were extracted from our old todo section into the new
[[Blueprint|blueprint]] section to store our research and plans in a
......@@ -118,7 +118,7 @@ Infrastructure
- Our Puppet modules were [published](
This was a first blocker before we can welcome contributions to
our infrastructure.
- The system that hosts our [[!tails_redmine "" desc="Redmine"]]
- The system that hosts our Redmine
was re-installed from scratch on a new machine, upgraded to Debian
Wheezy and to Redmine 1.4.4.
- Some improvements to our automated test suite were merged:
......@@ -85,7 +85,7 @@ ikiwiki will include your shortcut in the standard underlay.
# Local shortcuts
* [[!shortcut name=tails_website url=""]]
* [[!shortcut name=tails_redmine url=""]]
* [[!shortcut name=tails_gitlab url=""]]
* [[!shortcut name=tails_redmine_starter
desc="list of *Starter* tasks"]]
......@@ -35,7 +35,7 @@ You can have a look at:
- The [[list of known issues|support/known_issues]]
- The [list of things that will be in the next release](
- The [[!tails_redmine desc="rest of our open tickets on Redmine"]]
- The [[!tails_gitlab desc="rest of our open issues on GitLab"]]
<div id="bugs" class="blocks two-blocks">
......@@ -54,7 +54,7 @@ You can have a look at:
<h1>Request a feature</h1>
<p>If you would like to see a new feature in Tails,
search the [[!tails_redmine desc="open tickets in Redmine"]] first,
search the [[!tails_gitlab desc="open issues in GitLab"]] first,
and file a new ticket in there if no existing one matches your needs.</p>
</div> <!-- #wishlist -->
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