Tails

#1 Updated by intrigeri 2017-01-02 14:29:49

• Category set to Persistence

#2 Updated by sajolida 2017-01-16 19:30:29

• Assignee deleted (sajolida)

Ack. But I don’t want that on my plate for now…

#3 Updated by cbrownstein 2017-02-24 06:32:18

• File doc_deactivate_features.patch added

I added to the documentation instructions on how to delete files left by deactivated features.

Specifically, I added the following language, with appropriate markup, to wiki/src/doc/first_steps/persistence/configure.mdwn:

The files for features reside in /live/persistence/TailsData_unlocked. The files can be deleted safely from this directory. In order to delete the files, you need administrative privileges.

For example, to delete the files corresponding to the GnuPG feature, execute in a root terminal rm -rf /live/persistence/TailsData_unlocked/gnupg.

#4 Updated by intrigeri 2017-02-24 15:16:34

• Assignee set to sajolida
• QA Check set to Ready for QA

sajolida, do you want to review this?

#5 Updated by cbrownstein 2017-02-26 21:03:35

• File doc_deactivate_features.1.patch added

I have updated the previously submitted patch.

It occurred to me the user might not know which files correspond to a given feature. For that reason, I created a link to the “Manually copying your persistent data to a new device” page, which lists each feature’s corresponding folder.

#6 Updated by sajolida 2017-04-07 15:17:16

• blocks Feature #12432: Technical writing core work 2017Q2 added

#7 Updated by sajolida 2017-04-07 15:17:22

• blocks Feature #12431: UX core work 2017Q2 added

#8 Updated by sajolida 2017-04-14 16:35:17

• related to Feature #12448: Propose to delete data from deactivated persistent features added

#9 Updated by sajolida 2017-04-14 16:35:24

• blocked by deleted (Feature #12431: UX core work 2017Q2)

#10 Updated by sajolida 2017-04-14 17:23:11

• Status changed from Confirmed to In Progress
• Assignee changed from sajolida to cbrownstein
• QA Check changed from Ready for QA to Dev Needed
• Feature Branch set to doc/12109-deactivate-persistent-features

Again, sorry for the huge delay and thanks for the patch.

I’m very happy with the language but I have some concerns regarding the
workflow. We usually try to avoid as much as possible having people to
do stuff on the command line; and when we do so, we try to keep it as
simple as possible. Here I see two options to make it easier:

• We could instruct people to only start Nautilus on the command line
  (as we’re doing in /doc/first_steps/persistence/copy). I think this
  would make a big difference because the command line would be
  shorter and people wouldn’t have to adapt it to the folder that they
  want to delete. Also, from my experience with people who are not
  used to the command line, it’s usually fine for them to copy paste
  stuff in there blindly but one of the most confusing aspect is that
  successful commands do not return anything (silence means
  success). If we instruct them to open Nautilus it would have a
  visual result and then they would be in a familir visual environment
  to manipulate their files. Also, messing up with the command line
  cannot end up in deleting all their data which is the case with your
  proposal (imagine I type rm -rf /live/persistence/TailsData_unlocked/ gnupg).

• We could instruct people to use a regular Nautilus, open each of
  these folders, and delete the files in there. These folders belong
  to amnesia so they can delete their content (they cannot delete
  the folders themselves because TailsData belongs to root).

Also, in terms of workflow:

• I’m always happy to review plans or workflows for instructions
  before you write the actual text. You can comment on them on Redmine
  directly.

• Now that you have the Contributor role on Redmine, you can edit the
  metadata of tickets and, once you work is ready, you can assign it
  to me and mark it as QA Check: Ready for QA.

• I understand from your well-formatted patches that you are familiar
  with Git. So if you could host a copy of the repo somewhere that
  would be a tiny bit easier for me to work with. If that’s not much
  more work for you… otherwise I’m fine with patches.

• I pushed your work in the branch
  doc/12109-deactivate-persistent-features.

• You could also assign yourself some more end-user documentation
  tickets if you want. I can make you some suggestions if you want :)

#11 Updated by cbrownstein 2017-04-17 04:38:35

• File 0001-Rewrite-instructions-to-use-nautilus-instead-of-comm.patch added
• Assignee changed from cbrownstein to sajolida
• QA Check changed from Dev Needed to Ready for QA

I agree with you, for the reasons that you’ve stated, that using the command line to delete the persistent files isn’t the best approach. I’ve rewritten the instructions to use nautilus instead of the command line.

I’m attaching a patch; but I also have a branch (12109) at https://github.com/cbrownstein/tails/tree/12109

#12 Updated by sajolida 2017-04-28 13:54:38

• Assignee changed from sajolida to cbrownstein

Cool, thanks for the branch. I think the flow is much better now!

I adjusted 4 minor style issues in doc/12109-deactivate-persistent-features again (50ec97ff2d..69d4668eb2). Please have a look and tell me if I can merge that.

If you plan to continue contributing more doc (I hope so!) and never read a documentation style guide, I highly recommend reading one. It helps spotting small issues of style that make technical writing shorter, more precise, more consistent, less ambiguous, and easier to read and translate for international readers. For the Tails documentation I refer to the GNOME Documentation Style Guide first because Tails is based on GNOME:

https://developer.gnome.org/gdp-style-guide/2.32/gdp-style-guide.html

But also to the Apple Publication Style Guide and the Microsoft Manual of Style which all have their merits. Tell me if you want a copy of these :)

#14 Updated by cbrownstein 2017-04-28 23:52:56

• Assignee changed from cbrownstein to sajolida

Your edits are great. I’d say the branch is ready to be merged.

I’ll study the GNOME Documentation Style Guide. I always want to be learning.

Thank you.

#15 Updated by sajolida 2017-04-30 12:14:32

• Status changed from In Progress to Resolved
• Assignee deleted (sajolida)
• QA Check deleted (Ready for QA)

Merged then, thanks!

NB: Once the review process is finished we usually mark tickets as “QA Check: Pass”.