Diffstat (limited to 'wiki/src/contribute/working_together/roles')
8 files changed, 176 insertions, 35 deletions
diff --git a/wiki/src/contribute/working_together/roles/debian_maintainer.mdwn b/wiki/src/contribute/working_together/roles/debian_maintainer.mdwn
index f306c552..7bb10b7 100644
@@ -42,3 +42,11 @@ These packages are not part of this mission:
* [[!debpts torbrowser-launcher]]: we only use its AppArmor profiles,
that we could easily take from upstream if the Debian package was
+* [Debian release schedule](https://www.debian.org/releases/)
+* [Ubuntu release schedule](https://wiki.ubuntu.com/ReleaseSchedule)
+ * Upcoming: BionicBeaver, 18.04, April 26th 2018
diff --git a/wiki/src/contribute/working_together/roles/foundations_team.mdwn b/wiki/src/contribute/working_together/roles/foundations_team.mdwn
index 4b78ed7..27f41e0 100644
@@ -21,12 +21,26 @@ The Tails Foundations Team is responsible for:
those submitted by the [[release manager]], and the translation
merge requests sent to <firstname.lastname@example.org>;
+* checking how important each issue forwarded by Help Desk is, whether
+ it's worth documenting it, and validating the workarounds. If it's
+ worth documenting the problem and possibly the workarounds, either
+ put it on our Technical Writers' plate, or draft something directly,
+ or merge a draft proposed by Technical Writer apprentices;
* help triage new tickets that are on nobody else's plate when
frontdesk isn't in a good position to do it;
* ensuring that development discussions started on
<email@example.com> are followed-up;
+* proposing a release schedule for next year once Mozilla's own
+ schedule is available (generally during Q3), ensuring everyone
+ affected is aware of it and OK with it (e.g. team managers for
+ sponsor deliverables), leading this discussion to a conclusion,
+ updating the [[contribute/calendar]] accordingly, and asking
+ <firstname.lastname@example.org> to decide between themselves how they will share
+ the [[roles/release_manager]] shifts;
* if time allows, do whatever code task the project sees as
top-priority, such as fixing Holes in the Roof, important bugs, or
implementing a feature that is needed to keep Tails relevant.
diff --git a/wiki/src/contribute/working_together/roles/front_desk.mdwn b/wiki/src/contribute/working_together/roles/front_desk.mdwn
deleted file mode 100644
@@ -1,31 +0,0 @@
-[[!meta title="Front Desk"]]
- - Do user support by email:
- - Reply to bug reports received on email@example.com (empty reports might
- be silently ignored).
- - Reply to private user support requests received on
- - Improve the list of [[known issues|support/known_issues]] and [[FAQ|support/faq]] incrementally based on the work done by email, and do
- whatever small tasks will make the frontdesk job's easier in the future.
- - Based on users reports, gather information on compatibility in
- between Tails and Mac computers according to [[!tails_ticket 9315]].
- - Do user support on XMPP if you feel like it.
-General communication watchdog
- - Try to do something about the
- [new tickets](https://labs.riseup.net/code/projects/tails/issues?query_id=157)
- that appear in Redmine. An Atom feed is available for easier
- monitoring, see the link at the bottom of that page.
- - Administer and moderate our general purpose public mailing lists:
- - [firstname.lastname@example.org](https://mailman.boum.org/admin/tails-dev)
- - [email@example.com](https://mailman.boum.org/admin/tails-l10n)
- - [firstname.lastname@example.org](https://mailman.boum.org/admin/tails-project)
- - [email@example.com](https://mailman.boum.org/admin/tails-testers)
- - [firstname.lastname@example.org](https://mailman.boum.org/admin/tails-ux)
diff --git a/wiki/src/contribute/working_together/roles/help_desk.mdwn b/wiki/src/contribute/working_together/roles/help_desk.mdwn
new file mode 100644
@@ -0,0 +1,59 @@
+[[!meta title="Help Desk"]]
+Help Desk is handling individual support requests with two primary
+1. Gather qualitative and quantitative user data, that can be used:
+ - by the Foundations Team and UX people to prioritize their own
+ - by our broader community, to improve our understanding of who our
+ current users are, feed our thought process about our vision for
+ Tails in the future, and help us build a relevant roadmap.
+2. Help the bug reporter resolve the problem they are facing.
+ - Do user support by email:
+ - Reply to bug reports received on <email@example.com> (empty reports might
+ be silently ignored).
+ - Reply to private user support requests received on
+ - Act as a proxy between issues reported by users and the rest of
+ the project. Don't spend too much time investigating every such
+ issue, in particular for hardware support problems. Instead,
+ forward this information to the Foundations Team:
+ 1. Gather information about the context in which the problem
+ occurs, how important it is, what known workarounds exist.
+ 2. Forward the WhisperBack report over email.
+ 3. File a ticket assigned to a Foundation Team member, referencing
+ the WhisperBack report ID.
+ 4. Ideally, provide statistics about how many people are impacted.
+ 5. The Foundations Team will take a look and decide what to do
+ (e.g. addressing root cause of the problem, or asking Technical
+ Writers to document the problem and workarounds, or dismissing
+ - Follow-up on communications even when not on shift.
+ - Do user support on XMPP if you feel like it.
+General communication watchdog
+ - Try to do something about the
+ [new tickets](https://labs.riseup.net/code/projects/tails/issues?query_id=157)
+ that appear in Redmine; if you can't do anything, reassign to
+ a Foundations Team member. An Atom feed is available for easier
+ monitoring, see the link at the bottom of that page.
+ - Administer and moderate our general purpose public mailing lists:
+ - [firstname.lastname@example.org](https://mailman.boum.org/admin/tails-dev)
+ - [email@example.com](https://mailman.boum.org/admin/tails-l10n)
+ - [firstname.lastname@example.org](https://mailman.boum.org/admin/tails-project)
+ - [email@example.com](https://mailman.boum.org/admin/tails-testers)
+ - [firstname.lastname@example.org](https://mailman.boum.org/admin/tails-ux)
diff --git a/wiki/src/contribute/working_together/roles/sysadmins.mdwn b/wiki/src/contribute/working_together/roles/sysadmins.mdwn
index 8220c9c..bccad4e 100644
@@ -88,8 +88,9 @@ The main tools used to manage the Tails infrastructure are:
cases, we run the current stable release
a configuration management system
+ - our [[Puppet code|contribute/git#puppet]]
* [Git](http://git-scm.com/) to host and deploy configuration,
- including our [[Puppet modules|contribute/git#puppet]]
+ including our Puppet code
@@ -236,6 +237,16 @@ Below, importance level is evaluated based on:
- [[How to add checks to our monitoring setup|roles/sysadmins/adding_icinga2_checks]]
* importance: critical (needed to ensure that other, critical services are working)
+## Internal XMPP service
+* purpose: an internal XMPP service that can be used by Tails developers and some contributors.
+* access: at the moment everyone that is on the tails-summit mailinglist has and/or can
+ request an account.
+* tools: prosody
+ - `tails::prosody` in [[!tails_gitweb_repo puppet-tails]]
+* importance: low
* purpose: continuous integration, e.g. build Tails ISO images from
@@ -261,13 +272,18 @@ Below, importance level is evaluated based on:
* signing keys are managed with the `tails_secrets_jenkins` Puppet module
- web server:
* some configuration in the manifest ([[!tails_ticket 7107]])
+* design documentation:
+ - [[sysadmins/automated_builds_in_Jenkins]]
+ - [[sysadmins/automated_tests_in_Jenkins]]
* importance: critical (as a key component of our development process)
-* purpose: internal communication for the Fundraising team
-* access: Fundraising team members
-* tools: [[!debpts mumble-erver]]
+* purpose: internal communication for some internal teams
+* access: members of some internal teams
+* tools: [[!debpts mumble-server]]
- `mumble::*` parameters in Hiera
@@ -345,3 +361,7 @@ Below, importance level is evaluated based on:
- private keys are managed with the `tails_secrets_whisperback`
* importance: high
+# Other pages
diff --git a/wiki/src/contribute/working_together/roles/sysadmins/automated_builds_in_Jenkins.mdwn b/wiki/src/contribute/working_together/roles/sysadmins/automated_builds_in_Jenkins.mdwn
new file mode 100644
@@ -0,0 +1,32 @@
+[[!meta title="Automated ISO builds on Jenkins"]]
+We re-use the [[Vagrant-based build system|contribute/build/vagrant-setup]] we
+have created for developers.
+This system generates the needed Vagrant basebox before each build
+unless it is already available locally. By default such generated
+baseboxes are cached on each ISO builder forever, which is a waste of
+disk space: in practice only the most recent baseboxes are used. So we
+of the garbage collection mechanisms provided by the Tails
+- We use the `rake basebox:clean_old` task to delete obsolete
+ baseboxes older than some time. Given we switch to a new basebox at
+ least for every major Tails release, we've set this expiration time to 4 months.
+- We also use the `rake clean_up_libvirt_volumes` task to remove baseboxes from
+ the libvirt volumes partition. This way we ensure we only host one copy of a
+ given basebox in the `.vagrant.d` directory of the Jenkins user `$HOME`.
+script ensures a failed basebox generation process
+does not break the following builds due to leftovers
+such as filesystems temporarily mounted by `vmdebootstrap`.
+For security reasons we use nested virtualization:
+Vagrant starts the desired ISO build environment in a virtual
+machine, all this inside a Jenkins "slave" virtual machine.
+On lizard we set the Tails [[extproxy|contribute/build]] build option
+and point `http_proxy` to our existing shared `apt-cacher-ng`.
diff --git a/wiki/src/contribute/working_together/roles/sysadmins/automated_tests_in_Jenkins.mdwn b/wiki/src/contribute/working_together/roles/sysadmins/automated_tests_in_Jenkins.mdwn
new file mode 100644
@@ -0,0 +1,35 @@
+[[!meta title="Automated ISO tests on Jenkins"]]
+# Old ISO used in the test suite in Jenkins
+Some tests like upgrading Tails are done against a Tails installation made from
+the previously released ISO.
+In some cases (e.g when the _Tails Installer_ interface has changed), we need to
+temporarily change this behaviour to make tests work. To have Jenkins
+use the ISO being tested instead of the last released one:
+1. Set `USE_LAST_RELEASE_AS_OLD_ISO=no` in the
+ `macros/test_Tails_ISO.yaml` and
+ `macros/manual_test_Tails_ISO.yaml` files in the
+ `jenkins-jobs` Git repository
+ Documentation and policy to access this repository is the same as
+ for our [[Puppet modules|contribute/git#puppet]].
+ See for example
+ [commit 371be73](https://git-tails.immerda.ch/jenkins-jobs/commit/?id=371be73).
+ <div class="note">
+ Treat the repository at immerda as a read-only mirror: any change
+ pushed there does not affect our infrastructure and will
+ be overwritten.
+ Under the hood, once this change is applied Jenkins will pass the
+ ISO being tested (instead of the last released one) to
+ `run_test_suite`'s `--old-iso` argument.
+2. File a ticket to ensure this temporarily change gets reverted
+ in due time.
diff --git a/wiki/src/contribute/working_together/roles/technical_writer.mdwn b/wiki/src/contribute/working_together/roles/technical_writer.mdwn
index 924fc0b..42792af 100644
@@ -22,6 +22,10 @@ as a fallback if no other contributor volunteers to do it.
- Documenting new features, including [[doc/about/features]].
Documentation writing should be included in the budget if the
feature has one.
+ - Document known issues and their workarounds (e.g. on the
+ [[FAQ|support/faq]] or in the list
+ [[known issues|support/known_issues]]), based on information
+ provided by our Help Desk and triaged by the Foundations Team.
As technical writers have a limited amount of time to dedicate to these
tasks, Tails as a project should redefine priorities on a regular basis.