A couple of simple things can help manage things. It’s certainly important to prioritize issues with a limited set of resources, but that’s not really unique to this project. :) Which is to say, there’s a lot we can learn about how other groups do the same thing.

First, we can target all incoming issues to a particular revision. We can do that with on GitHub with either labels (my personally preferred approach) or milestones. The important thing here is that we decide fairly quickly what to aim at.

Second, we can branch the GitHub repository for each revision right now. They’ll be identical for the moment, but having the branches in place will help them change in parallel.

Third, we can try things out and put in document edits outside the calls. This includes hashing things out on the list and on the issue trackers. I’ve noticed that Kantara is particularly fond of its meeting processes, but sometimes work needs to get done before the consensus occurs. This may seem backwards to some, but I’ve found that people often don’t know what they like (or don’t like) until they see it laid down in front of them. Maybe they’ll love it or maybe they’ll hate it, but at least they’ll have something to either hate or love.

Finally, it’s just a change of mindset. It might seem strange at first working on a new version of something while maintaining a stable release, but with practice it becomes much more natural. Some people can focus on the new things, some people can focus on the maintenance, and some can do both. Overall, it’s a really powerful way to work.

 — Justin

On Aug 12, 2015, at 7:01 PM, Maciej Machulak <maciej.machulak@gmail.com> wrote:

Mike, Justin,

I reviewed the most recently sent list of issue nominations and I think that it might be better to start with targeting the issues marked for resolution today (13 August 2015). Lets first sort out these things taking into account what Eve commented on well in the other email thread - i.e. linear process of spec approvals. The proposed agile approach, honestly, sounds good to me!

I also need to agree with Mike regarding the number of calls that members can afford. Similarly, i'd be happy to hear Justin's comments what else could be maybe done to make some progress in parallel, if possible?

Cheers,
Maciej

On 12 August 2015 at 19:20, Mike Schwartz <mike@gluu.org> wrote:
In short: we don't have to wait, so let's not.

Justin,

I think Eve is doing a good job prioritizing the issues, and also getting feedback from the group on which issues to address. We've extended the calls to 90 minutes per week to specifically accommodate recent feedback we've gotten from implementers like you and others who are also now more actively engaged right now in development now that 1.0 came out.

I don't think the group can afford to have more than one call per week, as we did last year to get the initial 1.0 spec to the finish line.

I guess I'm wondering what else you think we can do to enable us to move in parallel like you suggest.

- Mike
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma



--
Maciej Machulak
email: maciej.machulak@gmail.com
mobile: +44 7999 606 767 (UK)
mobile: +48 602 45 31 66 (PL)
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma