Feature #14544

Spend software developer time on smallish UX improvements

Added by intrigeri 3 months ago. Updated 28 days ago.

In Progress
Target version:
Start date:
Due date:
% Done:


QA Check:
Feature Branch:
Type of work:
Affected tool:


This is about finding a way to do so, e.g. adding it to our Core budget for next year.

This is on our 2018-2019 roadmap but we need to act now so it can actually happen.


#1 Updated by intrigeri 3 months ago

  • Description updated (diff)

#2 Updated by intrigeri 2 months ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

I'll start by dumping some thoughts about this topic in the hope it starts a discussion and helps building a suitable proposal later on.

I'd like this to have a dedicated time budget (both for developers & UX person), not mixed with the existing Foundations Team and UX core work budget lines: otherwise I don't trust us much to prioritize this above the other many things that are in scope for these existing core work roles. I could elaborate if you want but I guess you get the idea.

I'm not sure if we should call this core work initially. I think this would be the first time we add improvements (as opposed to maintenance, fixing regressions and keeping relevant) to Core work:

  • If we do that, then it opens a much broader discussion, i.e. why not add improvements in other areas such as security too?
  • This year we were not able to fund all the core work, and some people had to do big parts of it as volunteers. If we add this new role to Core work, we'll need to be extremely careful wrt. how we prioritize paying it vs. paying other (really really needed) jobs. Let's take care of our team dynamics and do whatever we can to avoid frustration, especially when money is involved.

Ideally we would have data to select what actual improvement has the best cost/benefit. Thankfully we have initiated changes (in the Help Desk's mission, in having some budget for UX research) that will help us estimate the benefit; our developers can guesstimate costs.

I think we need a team built of:

  • one or two developers who are able to work on most of our code bases (i.e. proficiency in at least Python + shell + OS/desktop integration glue, and ideally Perl too although that can be delegated in an ad-hoc way); I think that restricts our realistic options to three individuals (I'll go into details privately);
  • one UX person.

Alternatively, the UX person could pick whatever developer has time and required skills, depending on the task. But I don't see a good way to make this work in a fluid manner with the cost/benefit approach proposed above. A permanent team has the advantage that it increases the chances the developer is involved in the process of picking the tasks, feels like they own the tasks more, is more motivated & less frustrated, and has a more user-centric approach to the problems at hand.

If I'm one the main developer, then I don't want this to be yet another set of WIP tasks that take months to complete: I don't need this in my mental space. And even if I'm not on board, a more focused approach to this work will save lots of context switches, waiting time between round-trips, and bureaucratic overhead. So I would go for a sprint approach (maybe twice a year?), piggy-backing on other sprints if possible, with the entire team (dev + UX) present face-to-face. This fits well with the smallish aspect, i.e. it forces us to pick a set of tasks that fits in a 2-4 days sprint. And it makes my "time budget" proposal realistic even with team members who don't clock their work usually.

#4 Updated by intrigeri 2 months ago

  • Assignee changed from intrigeri to sajolida

Also, in 2018 we want to work on #11679. I doubt we can do both at the same time, and I'd rather bring #11679 to the point where we know what we want to do exactly and how much it will cost, before we start this other area of UX improvements work => I would start this only in 2018Q4 + 2019Q1.

anonym, sajolida, what do you think?

#5 Updated by sajolida 28 days ago

  • Target version changed from Tails_3.3 to Tails_3.5

Also available in: Atom PDF