Hi all,
in some of the blueprints I am following, I have noticed that many work items updates (e.g. to DONE/POSTPONED/BLOCKED) are not accompanied by any additional information. Of course, not all work items need more information, but some are meaningless to an external viewer without it.
This is a general observation across Linaro and I am as guilty as any. As an example, consider the following (semi-fictional) work item updates:
+ Add Qt tracing support for pixmaps: POSTPONED + Create a bazaar branch for libX: DONE + Select and port an application to GLES2: DONE + Test that the application functions correctly on ARM: BLOCKED
These updates raise many questions: * Why was Qt tracing for pixmaps postponed? * What is the exact location of the published branch? * Which application was selected for porting? * Where can I find the ported code for the application? * Why is the application test blocked?
Such information is usually placed at the top of the whiteboard, like this (at least this is how I am doing it):
[alf May 8]: Postponed work on Qt pixmap tracing because it turned out we can trace Qt/Webkit without it, so it is not considered critical anymore. [alf May 10]: Uploaded branch to lp:libX [alf May 10]: Selected application Y for porting to GLES2 [alf May 12]: Finished porting Y to GLES2 and uploaded it to http://git.linaro.org/... [alf May 13]: Blocked on testing the ported application Y because of an issue (LP: #666666) with the 3D drivers for chipset Z.
In conclusion, I would like to encourage more verbosity in our updates, so that others can easily follow and appreciate all the great work that we are doing.
Thanks, Alexandros
On 24 May 2011 15:21, Alexandros Frantzis alexandros.frantzis@linaro.org wrote:
in some of the blueprints I am following, I have noticed that many work items updates (e.g. to DONE/POSTPONED/BLOCKED) are not accompanied by any additional information. Of course, not all work items need more information, but some are meaningless to an external viewer without it.
Perhaps we could improve the tools to encourage this/make it easier?
For instance, the work item format could be improved to let you add accompanying commentary to items rather than insisting on a strict one-line-only approach. As you say, you can add stuff at the top of the whiteboard, but that gets a bit messy and hard to cross-reference.
If work items were officially supported as a launchpad/blueprint feature then you could design the UI to encourage the addition of a little commentary when a work item is ticked off.
Proper support for named and timestamped comments (like bug reports have) might also help.
In conclusion, I would like to encourage more verbosity in our updates, so that others can easily follow and appreciate all the great work that we are doing.
Do many people find blueprints a useful method for following the detailed progress of a feature? (as opposed to general "65% complete" level progress tracking.) I have to say if I wanted to find out the current status of something I'd use IRC or email, as being much more likely to actually get me an answer that's usefully detailed and focused on the particular aspect I care about (and with forward-looking info like "we think we'll get that done next week").
-- PMM
On Tue, May 24, 2011 at 04:04:11PM +0100, Peter Maydell wrote:
On 24 May 2011 15:21, Alexandros Frantzis alexandros.frantzis@linaro.org wrote:
in some of the blueprints I am following, I have noticed that many work items updates (e.g. to DONE/POSTPONED/BLOCKED) are not accompanied by any additional information. Of course, not all work items need more information, but some are meaningless to an external viewer without it.
Perhaps we could improve the tools to encourage this/make it easier?
For instance, the work item format could be improved to let you add accompanying commentary to items rather than insisting on a strict one-line-only approach. As you say, you can add stuff at the top of the whiteboard, but that gets a bit messy and hard to cross-reference.
If work items were officially supported as a launchpad/blueprint feature then you could design the UI to encourage the addition of a little commentary when a work item is ticked off.
Proper support for named and timestamped comments (like bug reports have) might also help.
It really feels like it could be time to promote the work items to a real entity in launchpad. Has this been discussed before?
Many of the things we seem to want (ability to attach metadata, a proper audit trail, ability to mine) are natural database features, so it seems unfortunate that this all has to be achieved with scripts and obscurely formatted text buried inside text fields in launchpad.
But this situation has existed for a long time, so maybe it's not so simple as that... ?
In conclusion, I would like to encourage more verbosity in our updates, so that others can easily follow and appreciate all the great work that we are doing.
As a bodge, you can add extra text to the work item itself when changing its state, though this will quickly get unwieldy.
---Dave
On Tue, 24 May 2011 18:36:18 +0100, Dave Martin dave.martin@linaro.org wrote:
It really feels like it could be time to promote the work items to a real entity in launchpad. Has this been discussed before?
Many times.
It's not something that the Launchpad team is likely to work on at all this year, even if there was consensus on what should be done.
The Infastructure team could work on it, if it is high enough priority, but it doesn't seem to me that we have reached that point yet.
A better solution may be to stop using the whiteboards and just have everyone manipulate status.linaro.org directly. That's a fair chunk of work itself though, and again it needs to be high enough priority to beat out other things.
In addition, I'm wary of adding lots of extra features to workitems, as I feel they tend to be symptomatic of trying to load up engineers with too much process. We should always be careful to balance the desire for more information with the overhead that it causes. You can say that the features are optional, but having them there will always push people towards using them.
Thanks,
James
My solution to this is to file a bug and link it to the BP if it needs more than one line of info. This seems to work because anything that needs more than one line is probably not 2 days of work - which is what should go in the BP (which is my understanding). The bugs get picked up by status, so it all seems to work out.
On 24 May 2011 13:55, James Westby james.westby@linaro.org wrote:
On Tue, 24 May 2011 18:36:18 +0100, Dave Martin dave.martin@linaro.org wrote:
It really feels like it could be time to promote the work items to a real entity in launchpad. Has this been discussed before?
Many times.
It's not something that the Launchpad team is likely to work on at all this year, even if there was consensus on what should be done.
The Infastructure team could work on it, if it is high enough priority, but it doesn't seem to me that we have reached that point yet.
A better solution may be to stop using the whiteboards and just have everyone manipulate status.linaro.org directly. That's a fair chunk of work itself though, and again it needs to be high enough priority to beat out other things.
In addition, I'm wary of adding lots of extra features to workitems, as I feel they tend to be symptomatic of trying to load up engineers with too much process. We should always be careful to balance the desire for more information with the overhead that it causes. You can say that the features are optional, but having them there will always push people towards using them.
Thanks,
James
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 24 May 2011 20:31, Zach Pfeffer zach.pfeffer@linaro.org wrote:
My solution to this is to file a bug and link it to the BP if it needs more than one line of info. This seems to work because anything that needs more than one line is probably not 2 days of work - which is what should go in the BP (which is my understanding). The bugs get picked up by status, so it all seems to work out.
I found trying to link bugs to blueprints didn't work very well for me/qemu, so I'm avoiding it this cycle: * the linked bugs are listed in a different part of the blueprint page to the work items, so the todo list for the blueprint isn't in one convenient list * you can't mark a bug as 'postponed' to the next cycle (short of marking it wontfix) so you have to just unlink it, which means the entry just vanishes from the blueprint and status * also as you imply it's easy for a single linked bug to hide a big chunk of non-broken-down work
But I think the underlying thing I was hitting was that my bugs were generally user-reported ones that came in randomly during the cycle, so often only tenuously connected to the blueprints anyway. So linking bugs might well work better for the approach you suggest.
-- PMM
+++ James Westby [2011-05-24 14:55 -0400]:
In addition, I'm wary of adding lots of extra features to workitems, as I feel they tend to be symptomatic of trying to load up engineers with too much process. We should always be careful to balance the desire for more information with the overhead that it causes.
Very true.
I don't like blueprints either. Indeed I find them approximately useless and just another annoying thing one has to update from time to time along with weekly reports, etc. So far as I can tell they aren't for engineers - they are for managers to track progress, so from that point of view the current system does at least have the benefit of simplicity.
Making them more complicated _might_ make them more useful (which would encourage updating if engineers found them useful for day-to-day work), but more likely it'd just make them more tiresome to update, but still essentially uninteresting.
I'm afraid I don't know what the 'right' answer is, but I'm not convinced that 'more emphasis on, and process encoded in, blueprints' is it.
Wookey
W dniu 24.05.2011 20:55, James Westby pisze:
On Tue, 24 May 2011 18:36:18 +0100, Dave Martindave.martin@linaro.org wrote:
It really feels like it could be time to promote the work items to a real entity in launchpad. Has this been discussed before?
Many times.
It's not something that the Launchpad team is likely to work on at all this year, even if there was consensus on what should be done.
And this is why we should not keep being stuck with Launchpad.
The Infastructure team could work on it, if it is high enough priority, but it doesn't seem to me that we have reached that point yet.
A better solution may be to stop using the whiteboards and just have everyone manipulate status.linaro.org directly. That's a fair chunk of work itself though, and again it needs to be high enough priority to beat out other things.
Or we could just deploy Redmine and wait, less painfully, till Launchpad becomes a better productivity suite for teams of developers that are NOT working on a distribution.
In addition, I'm wary of adding lots of extra features to workitems, as I feel they tend to be symptomatic of trying to load up engineers with too much process. We should always be careful to balance the desire for more information with the overhead that it causes. You can say that the features are optional, but having them there will always push people towards using them.
While I agree with you completely about not throwing too much process at developers I need to stress not having a first-class work item "object" means we have no real tool, just a gimmick.
We should absolutely have work item history, we should also be allowed to "grow" from a simple one-line work item to something more resembling real tasks, with comments, code references, rich state changes, full history and participation of any number of people.
I know I'm biased here but Redmine provided all of that one year ago when we started and it still does today. Let's use it! It has all the right APIs for talking to status.linaro.org so we could retain our custom tools.
(shameless advertisement below)
If anyone is interested in Redmine (or just heard of it now) feel free to access my personal instance at http://fracture.suxx.pl/. In particular I would encourage *everyone* to look at my work item "rooster" at: http://fracture.suxx.pl/rb/taskboards/11
Each item there is a full-fledged task with all the features of a "launchpad bug" and more. I can just drag them around to indicate I'm done working on something. I can click on the task number to access the full rich state. If anyone is interested in _experimenting_ with this feel free to sign-in with your launchpad and either start a new project or ping me for being added to a group to work on validation projects).
Note: Redmine is not perfect by any means but it's hands down _better_ at solving blueprints + work items than Launchpad ever was.
Best regards Zygmunt Krynicki.
Each time when I spoke with Launchpad team I got a feeling that blueprint part of it is unwanted child which no one want to talk about.
Adding workitems as bug links allows to work around lack of history but they people which are subscribed to BP does not get updates from bugs.
Anyone with permissions can edit whiteboard and there is no way to check changes in other way then go through emails which many people delete just after reading.
I do not like this system but can accept it work.
On Wed, May 25, 2011 at 2:21 AM, Alexandros Frantzis alexandros.frantzis@linaro.org wrote:
Hi all,
in some of the blueprints I am following, I have noticed that many work items updates (e.g. to DONE/POSTPONED/BLOCKED) are not accompanied by any additional information. Of course, not all work items need more information, but some are meaningless to an external viewer without it.
This is a general observation across Linaro and I am as guilty as any. As an example, consider the following (semi-fictional) work item updates:
- Add Qt tracing support for pixmaps: POSTPONED
- Create a bazaar branch for libX: DONE
- Select and port an application to GLES2: DONE
- Test that the application functions correctly on ARM: BLOCKED
These updates raise many questions: * Why was Qt tracing for pixmaps postponed? * What is the exact location of the published branch? * Which application was selected for porting? * Where can I find the ported code for the application? * Why is the application test blocked?
Such information is usually placed at the top of the whiteboard, like this (at least this is how I am doing it):
[alf May 8]: Postponed work on Qt pixmap tracing because it turned out we can trace Qt/Webkit without it, so it is not considered critical anymore. [alf May 10]: Uploaded branch to lp:libX [alf May 10]: Selected application Y for porting to GLES2 [alf May 12]: Finished porting Y to GLES2 and uploaded it to http://git.linaro.org/... [alf May 13]: Blocked on testing the ported application Y because of an issue (LP: #666666) with the 3D drivers for chipset Z.
I've been thinking of using square bracket footnotes to add a bit more detail to things:
--- Work items: Design extension foo[1]: TODO Add support for Thumb-2: DONE Add to project bar[2]: POSTPONED
[1] will involve the kernel guys. Need to start this early. [2] postponed as it's been merged with blueprint X for next cycle. ---
To bikeshed a bit, I prefer sortable dates with the year like 2011-05-25.
-- Michael
-
Alexandros Frantzis -
Dave Martin -
James Westby -
Marcin Juszkiewicz -
Michael Hope -
Peter Maydell -
Wookey -
Zach Pfeffer -
Zygmunt Krynicki