On Sat, Aug 06, 2011 at 08:53:35AM +0100, James Westby wrote: > Linking a blueprint to a card > ============================= > > We have a few options here: > > 1. Put the link in the description and use a regex to pull it out > 2. Use the "URL for this specification" > - Can't link multiple BPs to a card without LP changes or hacks > - Means that we can't use that link for e.g. wiki notes on the work > 3. Create something like our TR BPs that represent the card on LP and > use dependencies as we do now. > > I propose option 1.
I'm fine with this, but let's not lose track of the fact that this is a hack! In other words, we probably want to figure out what the link to the external card URL actually means, conceptually, and figure out if there is a matching concept on the Launchpad side. > status.linaro.org > ================= > > Card view > --------- > > For this we really need an API for the cards. Does kanbantool have an > API? This is a risk. Just to confirm, you want an API to be able to run a health check on it. Is that right? Or is this for replicating the card details on status.linaro.org (to provide a public view of them)? > The page will include the expected milestone for each part of the work. For the blueprints linked to the card, in other words? > Lane view > --------- > > This will be similar to the front page that we have now, showing one > particular lane (Quarter for nearer things, longer time for further > away.) > > It will show the cards that are in that lane, with an indication of the > progress on them. > > You will be able to jump to the card view for any particular card. > > Estimate: 4 days to provide this view Will I be able to look at any lane (by hacking the URL, or maybe through a set of convenience links)? Is there any explicit 'initialize a line' script you'll need to run? > Milestone view > -------------- > > I'm not sure what we want to do here yet, it requires some more thought. > > Estimate: ? Maybe the Launchpad milestone page is enough for the first cut. What do you think? > Past work > --------- > > The lane views will be available for completed lanes so that you can see > what has been delivered. > > We may also want to produce aggregate information to show things like > things delivered in the past 6 months for a particular sponsor. > > Estimate: 2 days to provide something simple, another 3 days to provide > things like filtering by sponsor. This is a nice to have, IMO -- not critical for a first cut. > Blueprint/card health check > --------------------------- > > Each blueprint and card should have a "health check" that shows whether > it has what it needs. > > We will likely want to show a per-team view that just highlights > problems. > > Displaying most of this is likely pretty straightforward. Displaying > workitem parsing errors is more complex than the other parts. > > Estimate: 3 days for simple health check, 2 days for workitems errors, 2 > days for per-team view. I really like this part! > Launchpad milestones > ==================== > > I contacted Francis about whether we will be able to change the > milestone rules on Launchpad, and am awaiting a response. > > This is important if we wish to push some of the monthly visualisation > off on to Launchpad, otherwise we may be forced to provide the view in > status.linaro.org. > > This is a significant risk for this project. > > Estimate: 0 days, assuming that we can change this and the LP team does > it. Do you want me to talk it over in more detail with Francis? > AJAX workitem editing > ===================== > > While this would be nice to have, it isn't required as it will still be > possible to edit workitems in the current manner. > > A prototype in greasemonkey is likely the best way to approach this. I wonder if anybody in Ubuntu Platform has ever tried building one. > Bonus features > ============== > > I'm going to defer looking at this for now, except to stay that using > Launchpad milestone view for the team pages is apparently contreversial, > and so we should discuss that further. Really? Should I open a new thread? > So, it looks like we can take this on, with Mattias starting on it once > he finished hwpacks v2. Assuming we want this in two months, this > presents some risk, unless we have a backup plan for the next connect. I can also lend a strong hand here as I am blocking out some serious time to get this transition finished off by September. If you want to share some of the work plan with me I will help out. > So, I think we have the following to do from here: > > * james_w to go over the details again to try and find other work that > has to happen and so will affect the estimates, and to look for > other risks. This will particularly focus on milestones as that was > ignored above. > * james_w, joey, kiko to work with LP to get a satisfactory resolution > to the milestones issue, and come up with an alternative plan if > that isn't going to happen in time. > * kiko, would you look into whether kanbantool has an API? If it > doesn't then we can discuss alternative approaches. > > Now it would be great to have a system in which I could enter all the > work, split it up and estimate it :-) Hey, want a board for your own use? It's free to add new boards at the rate we are currently paying kanbantool.com for. -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs _______________________________________________ Mailing list: https://launchpad.net/~linaro-project-management Post to : [email protected] Unsubscribe : https://launchpad.net/~linaro-project-management More help : https://help.launchpad.net/ListHelp
