Coordinating Participation on GitHub

Mozillians
#1

For many months now the Participation Team has been using GitHub to coordinate as a team.

We work in three week sprints called “heartbeats” and each of these heartbeat kicks off with the creation of a series of issues that will move our quarterly goals forward, and which we believe we can accomplish in three weeks.

At the end of each heartbeat we meet to discuss which of our issues we were able to complete (or closed) and what stopped us from meeting the goals that we missed. We then share what we learned and our successes in a public “Demos” call that we invite everyone to attend. It’s been really effective for managing the staff team but there are many more people working towards participation goals!

We also work with a bunch of amazing contributors and it has been my task to figure out how to better integrate volunteers into our GitHub process.

Part one of this has been the realization that we don’t all need to be in the same Repo!

I recently created Repos for:

In these Repos the permission structure is this:

  • Contributors who are managing it have admin permissions
  • Staff who are advocates/helping manage the group are admins
  • Other staff or contributors who are involved can get write permissions by requesting it from current admins

Each of these Repos works a little differently but each one is a space for larger groups or projects related to Participation to create issues and work collaboratively on projects.

How To Use The Participation Team Repo:

My idea is that this Repo is for Participation Team Staff and for contributors who are working directly to move forward the Q1 Goals. Because the accountability structure is different between staff and contributors, there are a few labels and milestone that are different for contributor issues.

Permissions:

  • Admins are Participation Team Staff
  • Contributors who are regularly contributing towards the Participation Goals are given write access

Labels for contributor projects are:

  • Volunteer Driver - Projects that are being driven by a contributor
  • Volunteer Task - Projects look for contributor support
  • Owner Needed - Looking for a volunteer to take ownership of the project (issue won’t close without volunteer engagement)

Contributor Issues should be tied to one of these two kinds of Milestone:

  • Heartbeat Milestone i.e. H1 January 29th - For all issues that can close in one heartbeat, for anyone who wants to work within the heartbeat system and be accountable for their progress on a 3 week basis (mandatory for staff optional for contributors) (Note: Contributors who have issues in here will be invited to the accountability and demos meetings).
  • Quarterly Milestone i.e. Q1 Contributor Driven Tasks - For contributor driven projects that are longer-term and that either want to work outside of the heartbeat process, or for projects that want to record their quarterly goals in a “meta issues” in addition to their heartbeat issues. As for all things in this repo projects must be driving one of the OKR’s forward.

Please let me know if you have any thoughts, questions, or concerns!

3 Likes
#2

This begins to solve some of the tensions I’ve been observing the past year and feeling more recently as I’ve increasingly re-engaged.

Clarification on the milestones. Lets say I’m running a longer-term project that will last longer than a heartbeat, but I want to be accountable via heartbeat? Should there be a larger tracker issue that is broken up into single heartbeat issues? What would the milestone be for the larger tracker issue? Am I thinking about this right?

Are there known common blockers volunteers face that could be labelified? What about volunteer driven projects that require some kind of staff involvement to make timely progress? When volunteer driven projects (especially those working within the heartbeat system) require a staff member to unblock them in some way, this needs to be taken into account when setting reasonable expectations around project progress and achievability as well as staff capacity.

Aside from feedback on the github side of things, how would volunteers (especially accountable volunteers) integrate into the social side of heartbeats?

And a question more directly related to me, how might my work around the Participation Software Lab fit into this model?

(ps: the community feedback group github repo link is broken)

1 Like
#3

Oh, and which github issue is this proposal related to? Would love to see more cross-linking between discourse and github (where appropriate) as a common practice. :slight_smile:

#4

Hey Lyre!

Re: The Milestone Clarification

So for milestones, if you want to be accountable (sweet, sweet accountability) you should break your issue up into 3 week “bite-sized” chunks.

For example if my goal is to get the new NDA up and running I could create a larger initiative describing the entirety of the goal in the Q1 Objective. I would put that in the quarterly milestone, Q1 Participation Team Objectives for staff, and Q1 Contributor Driven Tasks for contributors.

I would then file the 3 week issue into the H1- January 29th milestone.

Re: Common Blockers

A lot of the work of being able to successfully close your issues at the end of each heartbeat comes from accurately guessing what you will be able to do in 3 weeks, and anticipating blockers.

For staff and contributors alike waiting on other people is usually the biggest blocker and largest factor in our ability to make timely progress. The process for flagging someone else is the same for staff and contributors, I recommend mentioning them in the comment of you rissue, but then also following-up by Skype, IRC, or email if you don’t hear back from them, being aware that often people are very busy and it might take a little time.

As you’re building your issues I recommend talking to the people you will need involved, and building your timeline together, so that they know the amount of time that you’ll need and can you can anticipate more accurately.

Another technique for this brings me to your question about…

Re: The Social Side of the Heartbeats

By which I assume you mean kick-off meetings, accountability meetings and demos.

IF you have issues in the H1 - January 29th Milestone you will be invited to the accountability meeting and to present at demos. (Email will be going out on Monday with more instructions and what to do if you can’t attend).

IF you attend that meeting (or do the offline work if the time doesn’t work for you to attend live) you will also be invited to create issues for the next heartbeat and attend the kick-off meeting the following week. The kick-off meeting is a great time to ask the people you will need what kind of time they’ll be able to give to your project, and get clear commitments early on.

Re: The Participation Software Lab

For this last one I will probably be the least helpful. The Participation Software Lab is a Q1 Objective that is still being developed.

It is owned by @pierros so he is responsible for creating the the heartbeat issues and assigning tasks within it. I recommend reaching out directly for more information about the work on this.

Hope that helps! Thanks so much for taking the time to read and comment!
Lucy

2 Likes
#5

Hey!

This proposal isn’t related to a single issue. It is more of a general discussion of several Repos, and then a deeper dive on practices and policies specific to the Participation Repo!

Lucy

#6

@lharris, would you mind if I combined your initial post with your followup response into a single draft document for later inclusion on the wiki?

1 Like
#7

Perhaps an update of this document should be in the cards as well: https://github.com/mozilla/participation-org/blob/master/CONTRIBUTING.md

#8

Yes to both!

-Lucy

2 Likes
#9

Hey @CaptainCalliope did you end up pulling this into a doc or wiki somewhere? Otherwise I might try and do that later today. Don’t want to duplicate efforts :wink:

Lucy

#10

Not yet. Have at it! Share and I’ll help streamline it a bit when I have time. :slight_smile:

#11

so a heartbeat is a timeline (3 weeks) and a milestone is a goal to be completed in one heartbeat.

Those two terms always confused me. Thanks for writing this post.

#12

Almost! So a “heartbeat” is a 3 week period of time. A “milestone” is just the GitHub term for a deadline.

So you have goals (issues) that you want to accomplish within a heartbeat so you add them to the next heartbeat milestone. That will indicate that you want to use the end of the heartbeat period as a deadline.

You can also choose to add your goal to the quarterly milestone, which indicates you want to use the end of the quarter as a deadline instead.

Does that help?
Lucy

#13

Yes. Was just trying to understand difference between heartbeat and
milestone. Thanks.

#14

This is still broken. Was this created or we quited on the idea? cc @lucyeoh

#15

What does it mean when some issues are listed as h1 or h2? Is each quarter divided into heartbeats so these are dates?

#16

Hey @jgmac1106 each quarter (quarter of the year) is divided into roughly 4 heartbeats (3 week periods). h1 refers to heartbeat 1 (the first heartbeat of quarter 1), h2 is heartbeat 2 etc. If you click on the milestone you’ll see the last date of that heartbeat period.

Hope that helps!

Lucy

#17

Hey Ioana!

Right now the community feedback repo is listed as private (I just added you) it depends whether we want to put details of NDA’d comms in here or just use it for more general project management. @dricupello is going to be adding issues to this repo this week and we can talk about how we want to use it at our next meeting!

Lucy

#18

@lucyeoh Did you end up turning this into a public doc?

#19

@CaptainCalliope I did not but it’s a wiki page waiting to happen! If you have time that would be AMAZING!

1 Like
#20

I guess that https://github.com/mozilla/participation-leaders-accountability/ it’s part of this initiative but is not used since an year, so maybe it’s better to close it to avoid confusion.