Document Core Contributors Sprints processes

[antoviaque]

This issue is to follow up on a topic from the contributor meetup working group

See https://discuss.openedx.org/t/core-contributor-sprints-improvement-survey/6915/8 - document for core contributor sprints "when and where should I check in, meetings, other processes)"

Might be related to https://github.com/openedx/community-wg/issues/12

From @sarina :

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.

[kdmccormick]

+1 for adding explanations of processes like check-ins, meetings, etc to the documentation on the wiki (or wherever else the "Responsibilities of CCs" documentation ends up living). There's a bunch of things CCs are supposed to do, and I'd love if they were all in one place.

[sarina]

To copy my most recent comment from the forums:

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)

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]

FYI @cassiezamparini ^ - you mentioned having had some feedback about the need to have better documentation about processes

I'm still assigned on this task, but it hasn't been mine in a while - would you want to take it?

[cassiezamparini]

@antoviaque I'd be happy to. It goes hand in hand with the work @ali-hugo and I are doing :)

[antoviaque]

@cassiezamparini Great, thank you! I'm assigning this issue to you then.

[cassiezamparini]

Awesome @antoviaque I'm going to hold on this until we get the results from the CC Survey.

[antoviaque]

@cassiezamparini OK - I'll put this in the follow-up column for now then.