Update PO files.
[tails/vicves.git] / wiki / src / blueprint / better_task_manager.mdwn
blob336c0dfcfead9922fb2afcf2bf763d35595da18a
1 Our current approach to managing Tails [[!tails_todo "" desc="todo"]]
2 does not scale. We have some ideas to improve it slightly, but it's
3 unlikely the result will be good enough, so we will instead migrate
4 to Redmine.
6 [[!toc levels=2]]
8 # Roadmap
10 **All this was done!**
12 See our [migration scripts](https://git-tails.immerda.ch/ikiwiki2redmine/).
14 * write a conversion script to import our existing
15   tickets (see *Convert and import* section below).
16 * update developers documentation
17 * migrate!
18   - import existing tickets
19   - setup rewrite rules from the ikiwiki tickets URL to the new ones
20   - remove tickets that are not blueprints from ikiwiki
21 * If needed, have additional plugins packaged and installed to fine
22   tune our processes.
24 # Wiki / Tasks
26 Let's keep our wiki for blueprints and research for long-term big next
27 features.
29 Let's try not to use the wiki for tasks (else it defeats the purpose of
30 tracking tasks), let's not try to use the tasks manager for research and other
31 things that would be better suited for the wiki (else it harms mostly-offline
32 developers).
34 # Specifications
36 ## Must have
38  * Should have categories (and display the related tasks in a meaningful way).
39    => Redmine, bugs-everywhere
40  * Should let us assign tasks to individuals
41    => bugs-everywhere
42  * Can handle tasks and sub-tasks
43    => Redmine, bugs-everywhere
44  * Create tickets over email.
45    => Redmine, bugs-everywhere
46  * Reply to tickets over email.
47    => Redmine, bugs-everywhere
48  * Being able to search through tickets offline (caching).
49    Ability to import a DB dump into a local instance of the webapp would be
50    an acceptable way to do it, even if clearly suboptimal.
51    => bugs-everywhere
52  * Email notifications: subscribing to a ticket, or to new tickets, etc.
53    => Redmine (for existing tickets), bugs-everywhere
54  * Advanced search queries, or filters (among metadata)
55    (roadmap, milestone, overview, individual dashboard)
56    => Redmine
57  * Hosted somewhere else **or** fully available in Debian
58    (or all deps in Debian? to be discussed if need arises.)
59    => Redmine (Riseup Labs & in a little bit outdated Debian),
60       bugs-everywhere (needs some care)
61  * milestones (target version)
62    => Redmine, bugs-everywhere
63  * Random users may reply to tasks.
64    => bugs-everywhere
66 ## Important
68  * Blocking property
69    => Redmine, bugs-everywhere
70  * Change a ticket's metadata via email.
71    => Redmine, bugs-everywhere
72  * Due time, deadlines
73    => Redmine (with email reminders), bugs-everywhere
75 ## Bonus
77  * Having tags
78    => bugs-everywhere
79  * Possible to assign tasks to a team / to multiple people
80  * Sub-tasks having precedence support or wait state or something that makes
81    the "let's create all future sub-tickets for a task at the same time"
82    workflow practically doable (i.e. I don't want to be shown all future steps
83    that are blocked by the first one)
84  * Possible to change a ticket's state from Git commit messages (todo->pending),
85    bonus points if merging that branch into stable ->done, or something like
86    that.
87  * Reminder for deadlines.
89 ## Unsorted
91  * Encryption support.
93 # Redmine
95 * [homepage](http://www.redmine.org)
96 * easy to setup thanks to the Debian package
97 * supports [issue creation or comments via
98   email](http://www.redmine.org/projects/redmine/wiki/RedmineReceivingEmails),
99 * supports [updating ticket attributes over
100   email](https://we.riseup.net/cgdev/using-email-with-redmine#sending-emails)
101 * the email interface, according to someone I trust who set it up and
102   uses it, is quite fragile and can be a bit mysterious to setup
103 * apparently, there no more powerful way to interact with it
104   asynchronously ([feature request for offline
105   mode](http://www.redmine.org/issues/2728))
106 * Textile syntax. Pandoc knows how to convert our existing Markdown to
107   Textile, but still, having Markdown support would be awesome.
108 * Git integration won't easily work with our many-branches workflow,
109   but we can probably do without for a while.
111 ## Plugins of interest
113 * Markdown syntax.
114   A blocker is that each such plugin switches the syntax
115   instance-wide, no way to enable it for a single project.
116   - [redcarpet formatter](https://github.com/alminium/redmine_redcarpet_formatter)
117     In Debian unstable ([[!debpkg redmine-plugin-markdown]]).
118     Marked as compatible with 1.x and 2.x,
119     but the packaged version is the one for 2.x.
120     Depends on [[!debpkg ruby-redcarpet]] that is in Wheezy, but not
121     in Squeeze, and may be a pain to backport due to a few missing build-deps.
122   - [Markdown formatter](https://github.com/bitherder/redmine_markdown_formatter)
123     Depends on [[!debpkg ruby-rdiscount]] that is in Wheezy, but not
124     in Squeeze, and a pain to backport (due to the gem2deb (>=
125     0.3.0~) dependency). Untouched since 2010.
126   - [Markdown Extra formatter](https://github.com/juno/redmine_markdown_extra_formatter/tree)
127     Depends of [BlueFeather
128     gem](http://ruby.morphball.net/bluefeather/index_en.html) that is
129     not in Debian. Untouched since 2010.
130 * [Carousel](http://www.redmine.org/plugins/redmine_carousel): can be used
131   for periodic actions that occur during project development process. It
132   automatically generates issue assigned to the next user in the carousel
133   queue every specified time period. Marked as compatible with 1.1.x
134   and 1.4.x.
135   > Looks interesting, but most (if not all) tasks we do switches for
136   > depend on our availability etc., so I'm not sure an automated
137   > solution would do. --intrigeri
138 * [Digest](http://www.redmine.org/plugins/digest): send a summary of a
139   project's activity over a period of time by email. Marked as
140   compatible with 1.4.x and 2.0.x. The [sample email
141   output](https://github.com/drewkeller/redmine_digest/blob/master/screenshot_emailoutput.png)
142   does not make me think this is any better than some way (feed
143   reader or rss2email) to subscribe to the project's activity.
144 * [Importer](http://www.redmine.org/plugins/importer): import issues in bulk
145   from .csv files. Compatible with 1.1.x. We do need this to import
146   existing tickets.
147   A [fork](https://github.com/ksauzz/redmine_importer/tree/redmine2.x)
148   supports Redmine 2.x.
149 * [Issue checklist](http://www.redmine.org/plugins/issue_checklist):
150   add checklist functionality to issues. Marked as compatible with
151   2.0.x -- what about 1.4.x or older? Having something lighter than
152   sub-tickets could be good, but certainly not critical. We'll see.
153 * [Git branch hook](https://github.com/mikoto20000/redmine_git_branch_hook):
154   add issue related revision by branch name. Can close tickets
155   on merge. One apparently may configure the branch that, when
156   merged into, triggers this behavior, thanks to the
157   `merge_branch` setting. Apparently impossible to use it for
158   the two-steps pending + fixed workflow we've been using,
159   but we may want to change this when switching tools anyway.
160   According to Git log, should at least support Redmine 1.4.x and
161   2.0.x.
162   We can start using Redmine and see later how much we need something
163   like this.
164 * [Silencer](http://www.redmine.org/plugins/silencer): suppress email
165   notifications (at will) when updating issues. Marked as
166   compatible with 1.1.x, not with 1.4.x.
167   > I'm not sure why we would want this. --intrigeri
168 * [Whining](http://www.redmine.org/plugins/redmine_whining): email alerts
169   when an issue had not been updated since X days. Marked as
170   compatible with 1.1.x, not with 1.4.x.
171   Would be very useful, looks easy to package and install.
172 * [Custom Workflows](http://www.redmine.org/plugins/custom-workflows):
173   define own rules of issue processing, e.g. change issue properties
174   or create sub-task if some conditions are met, enforce policies...
175   Marked as compatible with 1.2.x to 2.1.x.
176   Hopefully we won't need it, but it's still good to know it
177   exists.
179 ## Offline usage
181  * Sending an email can create an issue with:
182    - subject: mail subject
183    - description: mail body
184    - tracker: keyword (`Tracker:`) in mail body
185    - priority: keyword (`Priority:`) in mail body
186    - status: keyword (`Status:`) in mail body
187    - category: keyword (`Category:`) in mail body
188    - assignee: keyword (`Assigned To:`) in mail body
189    - kind of next thing to be done: keyword in mail body
190    - target version: keyword (`Fixed version:`) in mail body
191    - QA check (or any other custom field): keyword (name of the
192      custom field) in mail body
193  * Sending an email with '[#24175]' in the subject will add
194    information to the ticket. Same keywords as before can be used to change
195    metadata.
196  * Email address in From, To, or Cc are added to watchers (if they match
197    a Redmine user) when *creating* a new ticket over email.
198  * Clicking on *Watch* enables one to receive emails when the ticket changes.
199  * Every ticket has an Atom feed that contains all changes made to a ticket.
200  * There is an Atom feed with all open tickets, together with status and
201    description.
202  * Missing: set parent task, set related issues, delete ticket.
204 ## Convert and import
206 **Note**: this is an initial rough draft, that probably misses tons of
207 things to do, but should be enough to run some initial tests to
208 confirm the general idea is workable.
210 ### Set up Redmine
212 1. **done** Add a `External Id` custom field. Check "Used as a filter".
213 1. **done** Add a `QA Check` custom field. Make it searchable.
214 1. **done** Add a `Type of work` custom field whose possible values
215    are the same as our current `todo/*` tags:
216         Code
217         Discuss
218         Documentation
219         Pass Test
220         Promote
221         Qa
222         Research
223         Sysadmin
224         Test
225         Translate
226         Upstream
227         Wait
228         Website
229    Mark it as "used as a filter" and searchable.
230 1. **done** Add a `Blueprint` text custom field, with regexp `^https://tails[.]boum[.]org/blueprint/`.
231 1. **done** Add a `Fix committed` issue status.
232 1. **done** Make the `Fix committed` status available in Administration -> Workflow.
233 1. **done** Add a `Confirmed` issue status.
234 1. **done** Make the `Confirmed` status available in Administration -> Workflow.
235 1. **done** Mark the `Resolved` issue status as "Issue closed".
236 1. **done** Add an `Elevated` issue priority, rank it between Normal and High.
237 1. **done** Add a `Feature branch` custom field to ease review.
239 ### Adapt impacted stuff
241 1. **done** Prepare a branch that updates the website to advertise the new task
242    manager instead of the old one.
243 1. **done** Generate the Apache rewrite rules from the (External Id, Redmine
244    Id) mapping.
245    (`PRODUCTION=1 make rewrite-rules` should do the job.)
247 ### Clean up and gather data
249 1. **done** Close wishlist tickets not modified since more than a year.
250 1. **done** Split tickets that have several `todo/*` tags, and save the
251    parent/child relationship using `[[!parent]]`. In the end, each
252    ticket should only have one `todo/*` tag:
254         PRODUCTION=1 make list-more-than-one-todo-tag
256 1. Write a custom ikiwiki plugin to:
257    - **done** save original ikiwiki ticket name as `External Id` column
258    - **done** save parent/child relationship
259    - **done** wrap the whole ticket information into a CSV line
260    - **done** filter out `toc`
261    - **done** save `todo/*` tags into the "Type of work" column
262    - **done** save `release/1.0` and `todo/2.0` tags into the "Fixed
263      version" column, ditto for broken windows
264    - **done** turns `todo/qa` into `QA Check` == `Ready for QA`.
265    - **done** convert ikiwiki shortcuts to external links
266    - **done** turn internal links to non-todo pages into external links
267    - **done** convert Markdown to Textile
268    - **done** removes links to wishlist
269    - **done** converts TOC directive into Redmine's syntax
270    - **done** drops obsolete taglinks
271    - **done** import `priority/*` tags
272    - **done** import `category/*` tags
273    - **done** feed the blueprint custom field with the URL to the
274      relevant blueprint, if any
276 ### Freeze and import data
278 1. Run ikiwiki with this special plugin, then merge all these CSV
279    lines to produce a first CSV file that can be imported with the
280    Importer plugin.
282         PRODUCTION=1 make export1.csv
284 1. Import the first CSV file:
285    * use an account that has Manager privs on the current project
286    * ignore `Parent Issue` fields
287 1. Import this CSV file again to apply the relationships:
288    * use an account that has Manager privs on the current project
289    * use `External Id` as `Unique Column`
290    * check "Update existing issues"
291 1. Build a (External Id, Redmine Id) mapping
293        PRODUCTION=1 make ids.map
295 1. With a modified version of the ikiwiki plugin, plus this mapping
296    information, produce a second CSV files with tickets description
297    modified so that links to other tickets are updated to use Redmine
298    ticket linking syntax.
300         PRODUCTION=1 make export2.csv
302 1. Import the second CSV file, using `External Id` as `Unique Column`
303    again, and enabling the *Update Existing Issues* option.
304    Links between tickets should now be good.
306 ### Polish imported data and update the rest of the world
308 1. **done** Mangle the content of the Git repository:
309    * Move blueprints tickets to `wiki/src/blueprint/`: 
310      `PRODUCTION=1 make move-blueprints`
311    * Move attachments out of the way for future processing: 
312      `PRODUCTION=1 make move-attachments`
313    * Delete the rest.
314 1. **done** Manually take care of tickets sub-pages that were imported as
315    full-blown tickets. These sub-pages are used in too many different
316    ways to allow us to process them automatically:
317 1. **done** Manually add attachments (the Importer plugin does not support
318    this).
319 1. **done** Add some tickets relationships back.
320 1. For each ticket:
321    - Add a *Category* value.
322    - **done** Add a *Type of work* value.
323    - Decide if it should have been kept as a blueprint. If so, salvage
324      the content of the old ikiwiki ticket into a shiny new blueprint.
325    - If *Type of work* is *wait*, mark the ticket as blocked by the
326      relevant other ticket, if any.
327 1. **done** Move to the wiki stuff that should never have been migrated.
328 1. **done** Remove the `Qa` value from possible types of work.
329 1. **done** Mark the `Type of work` custom field as required.
330 1. **wontfix** Sort bugs and features to the relevant trackers.
331 1. **done** Add sub-tickets blocks/before/after relationships, starting with
332    tickets that are tagged `todo/wait` for another one.
333 1. **done** Remove the `External Id` field.
334 1. **wontfix** Clean `tags/*` up.
336 ## Setup
338 1. Install a Squeeze system with backports enabled.
339 1. Install packages:
341         apt-get install redmine/squeeze-backports redmine-sqlite/squeeze-backports
343 1. Follow the "QUICK LAUNCH USING WEBRICK" instructions in
344    `/usr/share/doc/redmine/README.Debian.gz`
346 1. Install the importer plugin:
348         cd /usr/share/redmine/vendor/plugins && git clone https://github.com/leovitch/redmine_importer.git
349         cd /usr/share/redmine && rake db:migrate_plugins RAILS_ENV=production
351 1. Install a backport of [[!debpkg ruby-fastercsv]], that's
352    a dependency of the importer plugin.
353    One has to decrease the build-dep on gem2deb to 0.2.7~.
355 1. Restart WEBrick.