And here is a PM-call-focused view of tickets that are “Community Priority” (and also Intro and Curated): http://104.131.56.36/#/pm
At a glance I see that:
many of our “community-priority” tickets have been stuck in statuses without activity for too long, including a couple that have been ready for work for >1 month => we need to do a better job of pointing volunteers to these tickets.
We have 69 open “curated” tickets and 25 open “intro” tickets. At first glance this doesn’t track well with the talk thread about how we don’t have enough intro tickets. => are our intro tickets too boring-sounding, or actually too hard to do?
A summary of last week’s scrums is less valuable than I thought it would be.
We don’t have a PM call on Monday due to MLK day, so I guess we won’t actually use this in a PM call until the week after, but I invite people like @wyclif, @dkayiwa, @raff, and @maany to check these out next week, especially to note the community-priority tickets that have fallen by the wayside.
(@michael and I are still looking to talk to Bitergia about using their software for more tracking of overall community activity and health; this is more some low-hanging fruit.)
We did have a productive conversation with Bitergia on 2015-01-18 and the design of their new platform (improving upon their previous MetricsGrimoire platform) should be able to accommodate all of our data sources (i.e., all of the places where our community activity is shown such as IRC, OpenMRS Talk, JIRA, Confluence, etc.).
I will be attending their workshop before FOSDEM and having a follow-up meeting to discuss a specific implementation strategy for their tools sometime during the FOSDEM event, so expect to hear some more news about this in the next few weeks.
Btw, @maany, @wyclif, @dkayiwa, @jdegraft, @raff I think it’s great that scrums are going on, and they’re starting religiously at the exact minute each day. I want to give you all a +1 for that.
Since I’ve actually read through all the scrum transcripts for the past two weeks, I have some feedback: we’re not actually doing scrum correctly in the way that provides us the most benefit.
The biggest gap is that we don’t have the “whole” team there, whatever that means in the OpenMRS context. There’s nothing that you all can do about this directly, but I’m hoping that reviewing the prior week’s scrums during the PM call will help some. Along with this, you can try to recruit more people to join.
But one actionable thing: blockers.
In any scrum where someone notes that they have a blocker, this should be treated with the highest priority, because it means that effort is being wasted. There should be some immediate, short conversation (I prefer this to be considered part of the scrum) about how to address the blocker.
E.g. yesterday both jdegraft and maany mentioned blockers, but there was zero conversation about this. See the logs.
I would agree. I will start following up on blockers as soon as everyone is done posting their updates. Or we could modify the !scrumoff command to automatically launch a blocker discussion mode after scrum ends.
Any recommendations besides discussing blockers on how to make scrum meeting more productive @wyclif@dkayiwa@raff@jdegraft ?
// random point : I feel that we should not stick to conventional scrum development as we are not always doing sprints and our scrum meetings do not always discuss activities related to sprints (which is a good thing as it paints the bigger picture of what’s happening in the dev community, but technically it is not a scrum meeting).
We might want to think of ways to increase participation as the daily irc scrums. Currently any developer who is working on a ticket is welcome to share his/her progress during the meeting but besides 4 or 5 folks no one hops in. Not sure if recruitment would be the right term, but if we could somehow make it part of the development lifecycle, I’m sure there would be more activity . For eg, before sending a PR, if the person shares his updates and is in the loop, it might be easy to review their work (early diagnosis of any pitfalls) and dev’s like @darius could also get a bigger picture of the dev side of things IMO (except the reviewers, hardly anyone of us takes part in JIRA discussions/ watches all active issues and hence the scrum log would be a good source to see all the issues being actively worked upon/merged )
FWIW, I still believe we are kidding ourselves if we can expect a globally diverse community of volunteers (i.e., people we’re not directly paying) to coordinate around a single meeting time every weekday. I subscribe to the Manifesto for Async Software Development and encourage everyone else to consider it too.
That said, there are practical replacements to our real-time IRC standup meeting that are proven successful with distributed teams elsewhere. Some example approaches include:
Anyway, I encourage people to think outside the box about how we can be more inclusive to people around the world to maximize participation. Telling everyone to show up in IRC at a given time is generally at odds with this approach.
(a) use technology to aggregate JIRA activity and comments into what you’d normally discuss in a scrum
(b) also have a daily time where key people (e.g. this week’s community dev lead, sprint lead of any active sprint, release manager for current release) review this for PM purposes, to identify blockers +/- identify things that we expect to be worked on that aren’t being worked on.
I do agree that a lot of community priority tickets have been ‘stuck’ for far too long. I’ll try and figure out these as well as fix some of them in the coming weeks as me and a few other new devs have been trying to.
Also, maybe the senior devs can look into ‘must’ and ‘should’ Issues and maybe convert a few of them into community priority tickets? We would love assisting them in this too.
Love the tool. Would love to get it at an easier-to-remember URL and maybe add a link from the overview to the PM view.
I agree any & all of the aspects of synchronous meetups that we can substitute with async & scripted solutions would be good; however, we shouldn’t overlook the beneficial parts of synchronous meetups in the process. Real-time group interactions, in person when possible (e.g., Summits & hackathons) and online (e.g., scrumversations or online hackathons), help feed the sense of being part of a group, can serve as motivators (“Gotta get this done in time for X”), and can be learning opportunities (e.g., communicating, interacting, speaking to a group, etc.).
At the moment I have put this on a random digital ocean box at my own expense. I will make a request to the infrastructure team via helpdesk about how I might deploy this on OpenMRS infrastructure, and then we can give it a memorable name. (But if you want to temporarily point om.rs/pm to it, feel free.
I’d like to clean this up to follow more precisely the specific points that we want to cover in our PM calls, for example:
Any broken builds?
Do we have enough community-priority tickets for devs to pick up?
Do we have enough curated intro tickets for newbies to pick up?
Overview of the state of community-priority tickets
(For community dev lead) any curated intro tickets stuck with no recent activity
Overview of the state of each of our upcoming releases in the Technical Road Map
Burke, Jamie, Michael, Wyclif, is there anything we talk about (or should talk about) in our PM calls that could be supported by some summary data from JIRA, Bamboo, etc?
