Core Contributor Sprints - Improvement Survey

@sarina Good point - I didn’t want to spam with too many threads, but it’s true that a very long thread can be difficult to approach. I’ll try using dedicated threads for each sprint, starting with the report for this sprint, today.

Thank you to everyone who has replied! I have uploaded the resulting responses:

Some of my take aways:


  • Most of the respondents are people already participating to the sprints: 13 out of the 17 responses (76%) submitted a response during the last check-in.

  • We thus didn’t have a lot of responses from core contributors who don’t submit check-ins, whom we were especially interested in, to understand how to make them more useful to everyone – but we still get some insights on the topic. If you’re one of these core contributors, don’t hesitate to comment on this, to get your insight and confirm/amend conclusions about this.

Sprint & check-ins rating

Among the ones who did participate, the average rating for the experience on a scale of 0 to 5 is 3.75, or 75% – which is not bad for an initial iteration, but could still use some improvements. It has the following distribution of answers:

Missing check-ins - lack of time for contributions?

The most common reason invoked for not posting the check-ins is the lack of time to make contributions, which would make the check-in useless (note: it isn’t useless - it helps us to know that already). It is the reason invoked for 2 of the 4 responses without a check-in, and came up a few times in response to individual emails I’ve sent to some of the core contributors who weren’t posting check-ins.

So it looks like the lack of time of core contributors is at least one of the main issues at play, when considering the proportion of check-ins that aren’t submitted – and can probably act as a proxy to measure it, as well as the impact of changes made to address it.

Missing check-ins - too much metawork?

Drawbacks to sprints are also pointed out, one of the answers without a check-in remarks that it adds some additional metawork for core contributors: “Sprints are useful, but right now they’re simply one sprint too many in terms of metawork.”

He also points to the duplication of information that’s already on boards: “since most of what I do now can be considered community work, there would be a whole lot of duplication involved in reporting it to yet-another-board”. It’s a fair point that technically since we work in the open, the information about “what has been done” and “what will be done in the next sprint / 2 weeks” should be somewhere already. Though in practice there I don’t think we have tickets scheduled in sprints for all the core contributor work planned, currently? It could be a good goal to have that for everyone.

Though I suspect that even then it would remain useful to sum up and present the work done?

Another direction on this could be to make updates more useful, to be worth the metawork for more people. Ideas are welcome on this. For example, we could do video updates instead of a list of bugs - it could be nice to see/hear it directly from the person, which is more personable and nicer? We do our own async sprint checks with videos at OpenCraft, and it’s a nice way to keep seeing regularly others, even when they are on another timezone. That might increase the interest of the what did you do / what will you do sections of the check-ins, making it likelier that others will read/watch them?

We don’t work together much

The other comment mentioned another issue with sprints, and core contributor work, at the moment: “It’s just seems that everyone is posting about their progress and no one works is related to one another” – which is sadly largely true. Making the work and needs of other core contributors more visible is a step to help, as it should provide more opportunities for collaboration. But those collaborations largely haven’t happened often so far – why not?

Maybe it would make sense to be more deliberate about assigning ourselves as core contributors to the various projects from the roadmap, keeping the number of projects small enough to have multiple core contributors on each?

Check-ins improvements suggestions

I’m not sure when we’re supposed to submit them? I start receiving pings in the middle of the sprint, at which point I haven’t worked on anything.

Yes, there has been some erroneous notifications sent, which have been confusing. They are now hopefully disabled. The real notifications are sent on Tuesday the 2nd week, with until Thursday evening to submit them. It’s not done at the very end of the sprint because we need time to discuss the blockers ahead of the following sprint and the contributors meetup, but you can submit an update for the previous 2 weeks on the day you make that report?

I’m also not sure were’s the documentation for CC processes (when and where should I check in, meetings, other processes)

That is true, currently this is only documented in the current forum thread - it makes sense to document it somewhere more appropriate, I have created a task about this and assigned it to myself: Document Core Contributors Sprints processes · Issue #61 · openedx/community-wg · GitHub @sarina Where do you think it would be best to put this documentation?

Emphasize collaboration and coordination in the questions. The most useful thing to come out of the check-ins so far for me was learning what Jill was working on, and trying to coordinate with her.
Maybe providing that responsibility to the working groups for a “divide and conquer” approach? So the working groups are their own cells. But during the contributor’s meetup or the core contributors sprints, the purpose of one of the meetings can be repurposed to coordinate between the working groups instead, depending on their needs/availability?

+1 on working on helping collaboration. How would it work with the workgroups exactly, though? We would have each workgroup submit an update for all its members, similar to what we have in the contributors meetup? Why not, and having them all async in the first place could be an improvement over the current purely synchronous working groups updates, where the right people with the information can be missing.

But how would the working groups collect that information from its members reliably? The advantage of the check-ins is that they are in place for everyone, there isn’t the need for each working group to put in place its own async check-ins, which take time to coordinate – instead, working groups can use the information from the check-ins, to build a summary?

Idea: organizations should nominate representatives, instead of having each CC do the reporting. This should reduce the overall burden.

Organizations or working groups? Having one person per organization reporting for them could help in some cases, but the core contributor work is meant to be a personal status and commitment, with hours provided by the employing organization. Though since these hours are the organizations commitments, it could be a way to keep them accountable to hold their promise?

I can only post a check-in when I receive an email reminder – there doesn’t seem to be a place in the UI to post them early.

True, I wish there was one – it makes the experience confusing, especially when notifications aren’t received, or bogus ones are sent. I don’t know of a way to do this with Friday currently, unfortunately. :frowning: If anyone has an idea, let me know.

I think if we want this to be more effetive, then it would be better if the sprint check-ins would be involved with CCs from the begging, for example if a CC doesn’t have much to do, whos job is to recommend or assign them a task…

You mean if some core contributors don’t report work for the following sprint, or don’t do enough hours, we suggest tickets or projects to them? That sounds like a good idea :+1:

Also a few comments approving the current check-ins :slight_smile:

I feel they are fine

Having more people filling them

They work well for me as they are. I can’t think of anything that could improve check-ins.

Not sure – they are very useful and take 2 min to fill out.

I think sprint check-ins are fine as they are now.

They seem fine to me.

Synchronous planning/retro meeting

The sycnhronous planning meeting had barely the average rating for usefulness, at 2.5/5 or 50%, and a majority of responses preferred to do everything async (9 out of 16, or 56%). The meeting time was also problematic, as it doesn’t work for 9 respondents (59%). The move to a full async process has already been implemented, and the synchronous meeting replaced by an async discussion of blockers, plus a synchronous discussion of any outstanding point at the contributors meetup.

Keeping the sprints?

At the question “Should we continue doing sprints for core contributors?”, we get 13 out of 17 yes (76%). It’s good to confirm that it’s useful for many! :slight_smile:

It would have been interesting to get this answer from more of the people who haven’t submitted their check-ins. The rating might have been lower – or some the others might have been happy to report contribution work if they had had time available for it?


Thanks for this, Xavier. I’ll cop to being one of the respondents that hadn’t checked in, in particular because:

This was recently discussed internally at tCRIL, as it of course doesn’t just apply to me. We came to the conclusion that doing this additional work is likely worth it for the added transparency. Sure, anybody can already check what I’m working on from the tcril-engineering board - or from the FWG, BTR, or Community boards - but that requires knowing about those in the first place. Whereas the CC sprint recap is both more concise and more heavily publicized.

So, to be clear, we - the official core contributors at tCRIL - will start doing check-ins like any other CC is currently encouraged to.

This doesn’t mean we can’t improve the process. So I like that you suggested:

I have mixed feelings on videos. They’re nice to make and have the advantages you list, but they take more time to scan than text, and this grows linearly (and faster than text) with the number of CCs checking in.

This brings me to something else: as participation grows, wouldn’t it be more practical to delegate this kind of meta-work to the working groups? One way or another, it already happens anyway. The main advantage I see would be in 1) as a CC, not having to do report on the same work to (at least) two different check-ins every two weeks, and 2) as anybody, it would be easier to follow what work is being done by area of concern.

There is also the question of time commitment and tracking, but not only is there another thread about this, we’ll likely gather in the conference to talk about it. Probably not worth tackling it here.

1 Like

To iterate on this, I have just tried adding a specific question about this at the end of the check-ins:

“Anything on which you could use help from other core contributors? That you would like to collaborate on?”

It will be included in the check-ins from this week (you should get a notification by email today - if not, let me know). I’ll also copy the items mentioned for that question to the report I’ll do in the forum thread this week.

Don’t hesitate if you have comments or suggestions about this, or on ways to iterate further.

1 Like

@arbrandes This is great, thank you for contributing those check-ins too! I’ll look forward to read about what you are working on. At tCRIL you are some of the most active contributors, and I’m sure we likely overlook a large part of your daily work.

Yes, it’s true that it does often take more time/energy than written updates. And since currently we’re more looking to get a broad range of reports, it makes sense to keep it small. Maybe those who want to post a video update could do that optionally?

Yup, it would be good to figure out a good approach to integrate with the working groups on this. I’ve brought up a way we could approach this above:

What do you think? We could then use those compiled reports in the contirbutors meetups? Having already the updates written async before the meeting could help to improve that meeting – by focusing on the discussions generated by the updates, and allowing to better represent and involve those who can’t attend the synchronous meeting? CC @jalondonot

Good question. I could see that possibly being captured in the README for the community-wg repo. Should be documented as well in the upcoming core contributor onboarding course, but it is a bit of a step up to click through a course to find info. I’d also make a page for in in the Core Contributors section of the wiki, even if it’s just a link (or - better - an embed) of the community-wg README.

1 Like

@sarina Thanks, I’ll add your comment to the description of the ticket, that will be useful. :+1:

What decides between documentation that goes in a wiki page, vs documentation that is versioned and goes on readthedocs, like Contributing to Open edX — Contributing to Open edX documentation ?

Really good question. Here’s why I suggested the wiki:

  • It already has a lot of Core Contributor content, so there may be people who go to this place for information.
  • We are in the process of revamping our documentation entirely (information architecture particularly) so it doesn’t feel like the right time to add a bunch of things to RTD. I think it would make sense to do so once there’s a clear place and the CC program is pretty well set (RTD is a bit harder to edit than a wiki, and to me feels more appropriate to use when process / code is becoming settled)
  • I am going to be adapting the content of the wiki into the CC onboarding course, so selfishly it is easier for me if the content I need to lift is referenced in one place (this also applies to an eventual RTD migration)

@feanil is the lead on the docs project, if you have any questions.

What I meant by “wiki”, by the way, was to simply make a new page in the Core Contributor page tree that links out to non-wiki references, to capture those for new people. I definitely don’t think you should duplicate content.

1 Like

@antoviaque I would love to leverage the Friday application to track non-code contributions to the platform, including marketing and Transifex activity. Should I use the existing Friday account for this purpose (plus survey), so that we can track everything in one place, or is the space solely dedicated for CCs?


@ehuthmacher It would be great to be able to integrate your check-ins there! It would help to expose more that information, while avoiding duplicates & keeping the overhead of updates low.

Ideally we would have a common check-in questionnaire sent to all cores, so we only have to track answers in one place – which would facilitate the recurring organizational work of collecting/chasing those updates.

What are the questions that you ask for the marketing and translation check-ins? Here are the current ones asked in the core sprint check-in – would those work, or are there changes you would like to make to them?

  • How did you feel about the sprint?
  • Checkin - What did you accomplish this sprint?
  • How many hours did you log over the last 14 days? (enter only the number of hours)
  • Retrospective - What went well with this sprint?
  • Retrospective - What should we improve?
  • What will you work on in the upcoming sprint, starting next week?
  • Any blockers?
  • Is there anything where you could use help from other core contributors? Or that you would like to collaborate on?

@antoviaque Ok great, I will integrate the check-ins on the existing platform. Regarding the questions, they cover all of the necessary basis, I would just like to make a few tweaks to fit the Marketing and Translation WG format:

  • Did you find today’s meeting productive? Why or why not?
  • Checkin - What did you accomplish in the 2 weeks leading up to today’s meeting?
  • How many hours did you log over the last 14 days? (enter only the number of hours)
  • Retrospective - What went well this month?
  • Retrospective - What should we improve?
  • What will you work on for the upcoming meeting?
  • Any blockers?
  • Is there anything where you could use help from other WG member? Or that you would like to collaborate on?

@ehuthmacher Great! Sounds good to integrate those changes – the only thing I would alter is to make them meaningful for those who aren’t part of a working group, so the same questions can be used for everyone. That could give something like:

  • Did you find the last two weeks productive, including the meetings from your working group if any? Why or why not?
  • Checkin - What did you accomplish in the last two weeks (aka “current sprint”)?
  • How many hours did you log over the last 14 days? (enter only the number of hours)
  • Retrospective - What went well these last two weeks / sprint?
  • Retrospective - What should we improve?
  • What will you work on for during the next two weeks / sprint?
  • Any blockers?
  • Is there anything where you could use help from others? Or that you would like to collaborate on?

Would that work? We can iterate until we find the right questions :slight_smile:

Btw, do all your working group members already receive the check-in notifications? Normally all the core contributors should already be on it, but if others want to participate, you can add them on this page: (“Invite people” button on the top right).

Yes, those questions are perfect, thank you! I will add the members accordingly.

I noticed that the founder of Friday has decided to close up shop:

Perfect - I’ll update the questions accordingly then. :+1:

Yup, this is unfortunate, just when we were starting to get used to the tool. :confused: At least we have 2 months to figure it out. I’ll take a task to move to an alternative – if you know a good one to suggest, don’t hesitate.

It might be an opportunity for us to close the loop and use something inside Slack itself? Hopefully there’s a Slack extension like Retrospective Dashboard we could use if you think it could work:

I’ve not tried it yet though.

@antoviaque I think it depends on what features you’re looking for. If exporting to a Google sheet is important to you, that may limit options - in that case maybe a timestamped Google Form would be best because data flows straight to the sheet.

At first glance I like Free Online Agile Retrospective Meetings | Parabol but I don’t know how you’d collect form input like “how many hours did you work”. I’m also not entirely certain you can see which user entered which item.

Exact Process to Run Remote Retrospectives Asynchronously [Effective and Fun] looks cool but I don’t think it’s free, but matches @Dean 's suggestion of everything-in-Slack.

Some sites suggest Miro, although I’m not 100% a fan of Miro. I’d use it though, and tCRIL has a license. I’ve similarly seen recommended - it has a limited free tier we could work with (only 3 boards, but unlimited users).

This article has a ton of suggestions about remote tools in general: Collaboration Tools for Remote Teams | Smartsheet

@Dean @sarina Thanks for the suggestions! Another one we have been using at OpenCraft is (tool makers were very inspired by days of the week, apparently ;p). It is good, but it has problems of its own (price, clunkiness, noisy notifications).

Another good suggestion several people have sent to me is Google Forms – it’s simple but would do the job, and allow easy exporting.

That said, a general issue with every single tool we have found so far is that they are closed source – which is a problem, especially for an open source project. We have tried many (proprietary) tools in that space over time at OpenCraft, and there is always a point where the processes don’t quite fit the tool, and without the ability to make changes to it, we ended up stuck.

Which is why I’ve looked into the possibility of re-using an open-source project we’ve been working on, to solve similar needs around our async reporting & checklist. I wasn’t sure we would be able to offer to adapt it in time to fit the core sprints needs before June, but it looks like @Fox_Piacenti @ali_hugo and @itsjeyd found a way to make it fit, if we want to pursue this. :slight_smile: So what do you think – could this be a good way to replace

Here are a few links to learn more:

Btw, one of the advantages of using an open source tool is that if you see something that doesn’t quite work or would be missing, we can change it – so don’t hesitate, especially now before the adaptations would be designed & developed.

1 Like


Days of the week :laughing:. Those domain names must be expensive. I see most of them are parked (the .com ones I mean). I guess soon the domain name will be available :smiley:

That open source solution looks good according to the design mockups. Using Google Forms would be ready-to-go with no overheads, plus easy exporting as you mentioned.


16 posts were split to a new topic: Core contributor sprints - New checkin interface