To address this retro feedback item, I have drafted a survey, to be sent to all core contributors: Core Contributors Sprints - Improvements Feedback Form – tests, reviews and improvements welcome! CC @sarina
This is done - now the field will allow to enter an arbitrary number of hours.
The reviews didn’t request any changes, so let’s start the survey – core contributors, could you respond to the following survey? It should be quick, about 5 minutes. Thanks!
There are still missing answers to the survey, so please fill it if you haven’t already: Core Contributors Sprints - Improvements Feedback Form
Since we don’t always have the right people to unblock the issues immediately at the sprint planning meeting, and that this is currently the main focus of the meeting, it might make sense to fully move that to an async discussion, on the forum?
I could also add an agenda item to the contributors meetup to discuss any remaining item that couldn’t be fully addressed async. That should reduce the number of items to a small list, and the bigger attendance of the contributors meetup could be better at addressing them.
I’ve just noticed that a second check-in was activated, and sent a notification by mistake on Friday (subject “Reminder for Weekly Review: please add an entry” ). The correct check-in has the subject “Core contributors - Sprint Retrospective & Planning: please add an update”. Sorry for the confusion!
In any case, please send your check-ins 
You should also receive an automated reminder from Friday today, and I’ll also chase people individually for answers to the survey and the check-in.
I’m in favor 
(post needs 20 characters)
Alright - I’ll cancel tomorrows’ sprint planning meeting then, to focus on the async version. I’ll build the report of blockers & recap as usual, based on the submissions of check-ins from this week.
So please submit a check-in if you haven’t already!
Thanks @antoviaque - I think it is good to experiment with format. Would it make sense to make a new thread for discussion, I could see as granular as per-sprint, or per-month, or per-quarter? 100+ long threads are a bit hard to approach for newcomers or people curious what we’re working on.
@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.
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:
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.
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?
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?
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/wg-coordination · 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. 
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
Also a few comments approving the current check-ins
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.
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.
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!
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.
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.
@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.
@sarina Thanks, I’ll add your comment to the description of the ticket, that will be useful.
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:
@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.
@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?
@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:
@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:
Would that work? We can iterate until we find the right questions
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: https://my.friday.app/directory (“Invite people” button on the top right).
Yes, those questions are perfect, thank you! I will add the members accordingly.
