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