| Thread Previous • Date Previous • Date Next • Thread Next |
Hi, There has been some confusion about what those changes actually mean and how they will affect the people and tools that make use of the Blueprint whiteboard to keep track of work items; I hope to clarify them here. Our goal with adding native support for work items in LP[1] is so that we can implement progress reports that take work items into account[2] instead of just Blueprints. Since the beginning we've planned everything so that for users there are no visible changes (i.e. they will continue to enter the work items in a text field using the exact same format as before). You can see that on the attached screenshot, together with the warning shown to prevent work-items from being accidentally entered into the whiteboard. Although we put the warning to prevent workitems from going into the whiteboard, if somebody accidentally does that it will be trivial to manually migrate them as the two fields use the same format and UI. Also, notice that LP now parses/validates the work items (using the same rules used by status.u.c) when the user saves them, so we should no longer see parsing errors on status.u.c. We also didn't want the existing tools (i.e. launchpad-work-items-tracker) to have to be rewritten to work against native work items, but that came naturally as we didn't change anything for users. In order to keep lp-wi-tracker (status.u.c) working we just had to change it to get the WIs from the new field instead of the old one[3]. Since the format is the same in both fields, the rest will just work (famous last words, yeah ;). If there are any other tools extracting work items from the whiteboard, they will also need to get them from the new API attribute (.workitems_text). Once those changes are live we are going to migrate the work items from the whiteboards of all Blueprints to the native format. This should happen only a few minutes after the changes have gone live and from then on the work items will appear in the new field under the whiteboard, using the same format we have today. Out of the ~2500 Blueprints we have with work items, around 270 (only 150 of those created after 2011-01-01) cannot be migrated[4] because they have work-items that cannot be parsed, so in those cases we will leave the whiteboard unchanged and notify the BP owner/assignee about the failure to migrate. For those BPs they can, in less than a minute, copy-n-paste the workitems from the whiteboard to the new field, fix the errors reported and save them, to have them migrated. All of the above is implemented, QAed and we're confident it can be put in practice without causing any significant disruption to the users of Blueprints in LP, but we understand that there may be some concerns with this so we're happy to delay this until we've dealt with them. [1] https://lists.launchpad.net/launchpad-dev/msg08782.html [2] https://dev.launchpad.net/Projects/WorkItems [3] https://code.launchpad.net/~salgado/launchpad-work-items-tracker/use-new-workitems-lp-property/+merge/96135 [4] https://lists.launchpad.net/launchpad-dev/msg09104.html -- Guilherme Salgado <https://launchpad.net/~salgado>
Attachment:
new-wi-ui.png
Description: PNG image
Attachment:
signature.asc
Description: OpenPGP digital signature
| Thread Previous • Date Previous • Date Next • Thread Next |
