Commit fb581ad6 authored by sajolida's avatar sajolida
Browse files

Merge remote-tracking branch 'origin/feature/15878-gitlab' into feature/15878-gitlab

parents f673ce45 49c91f4b
......@@ -68,14 +68,6 @@ Merge policy
See our [[contribute/merge_policy]].
If you intend to prepare Tails releases, you'll need to make
the development team signing key the default one for Git tags:
git config user.signingkey A490D0F4D311A4153E2BB7CADBB802B258ACD84F
......@@ -50,7 +50,7 @@ To submit your branch for review:
- Summarize what problem this MR will fix, in terms of impact on users.
- Reference the issues this MR will solve: `Closes #xxx, #yyyy`.
- If it's obvious to you who can, and should, review your branch: assign
the MR to that person.
the MR to that person.<br/>
Else, leave the MR unassigned:
the [[Foundations Team|working_together/roles/foundations_team]] will
either handle the review themselves or help you find a suitable reviewer.
......@@ -55,7 +55,7 @@ Priorities for the next years
- <strike>**Release Tails 4.0 based on Debian Buster** ([[Version 4.0|news/version_4.0]])</strike> [DONE]
- **Solve important usability issues** in our core applications
([[!tails_gitlab tails/tails/-/issues?scope=all&utf8=✓&state=opened&label_name[]=UX%3Acandidate]])
([[!tails_gitlab tails/tails/-/issues?scope=all&utf8=✓&state=opened&label_name[]=UX%3Adebt]])
- **Port complex shell scripts to Python** ([[!tails_ticket 11198]], [[Blueprint|blueprint/Port_shell_scripts_to_Python]])
- <strike>**Migrate from `aufs` to `overlayfs`** ([[!tails_ticket 8415]])</strike> [DONE]
- **Have more robust time synchronization** when starting Tails ([[!tails_ticket 5774]], [[Blueprint|blueprint/robust_time_syncing]])
......@@ -17,7 +17,8 @@ For general GitLab usage information, see the
To create your GitLab account, visit the [[!tails_gitlab users/sign_in
desc="registration page"]] in a web browser.
Then you will be allowed to open new issues and merge requests.
Then you will be allowed to open new issues, create merge requests, and fork
your own copy of our repositories.
Later on, you will probably need to [[request more
......@@ -161,12 +162,20 @@ Every open issue must have exactly 0 or 1 of these labels:
- _P:High_
- _P:Urgent_
See the
[[!tails_gitlab groups/tails/-/labels?search=P%3A
desc="list of priority labels"]].
## Category
We classify issues with labels whose name starts with _C:_.
For example, _C:Email Client_ or _C:Installation_.
See the
[[!tails_gitlab groups/tails/-/labels?search=C%3A
desc="list of category labels"]].
## Type of work
To indicate the type of work that's needed to complete the next step
......@@ -183,6 +192,10 @@ For example:
people to do, outside of Tails
- _T:Website_: website work not covered by other options
See the
[[!tails_gitlab groups/tails/-/labels?search=T%3A
desc="list of type of work labels"]].
## Other labels
- _Starter_: issues flagged as *Starter* can be a good pick for new contributors
......@@ -227,9 +240,20 @@ A confidential issue is visible only by:
access; that is, for our [[!tails_gitlab tails/tails desc="main GitLab
project"]]: most past and present Tails contributors
<div class="caution">
Only share the URL of an attachment with people you want to allow downloading
that file.
In contrast with Redmine, that enforced access control on attachments, with
GitLab, anyone can download <emph>any</emph> attachment if they know its URL.
This applies equally to attachments added to a confidential issue.
If your team regularly manipulates confidential data, then its issues live under
a dedicated GitLab project, with a different set of members, and possibly
configured so that new issues are confidential by default.
only visible to project members.
<a id="document-progress"></a>
# How to document progress
......@@ -168,15 +168,15 @@ See [[contribute/working_together/GitLab#assignee]].
## UX improvements
Our [[UX designers|roles/ux]] maintain a
[[!tails_gitlab groups/tails/-/issues?scope=all&utf8=✓&state=opened&label_name[]=UX%3Acandidate
[[!tails_gitlab groups/tails/-/issues?scope=all&utf8=✓&state=opened&label_name[]=UX%3Adebt
desc="list of UX improvements"]] that would be welcome,
using the "UX:candidate" label.
using the "UX:debt" label.
From time to time, some Foundations Team members meet with UX
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
[[!tails_gitlab groups/tails/-/issues?scope=all&utf8=✓&state=opened&label_name[]=Core%20Work%3AFoundations%20Team&label_name[]=UX%3Acandidate
[[!tails_gitlab groups/tails/-/issues?scope=all&utf8=✓&state=opened&label_name[]=Core%20Work%3AFoundations%20Team&label_name[]=UX%3Adebt
desc="our list of tasks"]].
That is, working on them automatically qualifies as Foundations Team work.
......@@ -185,7 +185,7 @@ 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 an issue that has the "UX:candidate" label,
particularly interested in working on an issue that has the "UX:debt" label,
but that was not added to our plate yet.
It is an option to turn one such issue into Foundations Team work,
provided a few conditions are met.
......@@ -200,7 +200,7 @@ these conditions:
You can check yourself if a particular issue meets all these
- Our UX designers added the `UX:candidate` label.
- Our UX designers added the `UX:debt` label.
- It is possible work on it without waiting for lots of UX work to be done first.
To determine whether that's the case:
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