We’re planning to change the Champion program; instead of 1-2 edX point people that you would reach out to with questions, we’re migrating to a set of shared Slack rooms, broken up by repo category, that you will use to ask edX engineering collectively for assistance - usually that’s “when’s a good time to merge this PR”, but other questions as well - anything you would have normally pinged your Champion for.
I will be shortly inviting you to slack room(s) based on the repo(s) you have merge rights to. You may join others if you wish. Please know, though, that these rooms will mostly be discussing how merging affects edX CI/CD, edx.org production systems, and other practical concerns. These rooms are not for questions along the lines of “help me write the code”.
For awhile I will monitor each chat room to make sure this goes smoothly. Reach out if you have any questions.
That makes sense to me as a transition step I assume the intent, over time, is to share the original duty of the champions (as mentors?) more, and maybe to get to a point where that help can come not just from edX, but from other core contributors?
For the chat rooms, one thing that it changes though is that there isn’t going to be a specific person affected to mentor each new core contributor – how do we avoid the “dilution of responsibility” effect on this? For example, if a core contributor asks a question in a chat room, and that there is no answer, what would be the next step for the core contributor to get help? [Edit: This is actually something already addressed in the document you’ve linked to, which I should have read more carefully before replying “One potential failure mode is that 2U/edX engineering does not participate in these rooms. We will mitigate this with one engineering manager per room whose responsibility is to make sure questions are responded to in a timely manner. The EM should aim to check the room daily and get coverage when on vacation. The spreadsheet of Slack channels has a nominated EM, as well.”]
How complicated would it be to make the rooms public? Imho it would be much better to default to public communication for everything related to core contributors – the program and the shift to tCRIL is a unique opportunity to ensure we hold more of our discussions in the public space. Things that might have been private before when the matters were internal to edX can be made public more easily in the context of community collaboration – and the example we set as core contributors has ripple effects on the community. It’s harder to ask newcomers to work publicly if we don’t already do it – and it will be harder for people looking to become core contributors to understand the role if they don’t have access to spaces like this.
I think we can manage this through channel policies (and, if needed, moderation), redirecting people to the right places to get help? I would assume people would prefer a gentle redirect to ask a question in another place, to not being able to access the space at all?
@antoviaque we’d have to remake all the rooms, I think, and would need assistance for the edX side. I was busy and tired and frustrated and didn’t want to go through the whole cycle again. I am very torn about the public rooms, though, as I am worried that non-CCs could abuse the promise of a quick turnaround time from edX devs and in turn edX devs would be disincentivized to respond quickly. I don’t probably have the bandwidth to moderate moderation/do redirects, and from my experience with #general, there aren’t many people who step up to help redirect questions.
I assume the intent, over time, is to share the original duty of the champions (as mentors?) more, and maybe to get to a point where that help can come not just from edX, but from other core contributors?
The intention of these rooms are not to get particular coding help from edX or CCs. these rooms I imagine will almost exclusively be used by CCs, as a conduit to edX for as long as edX is deploying off the tip of master, for questions such as “Can you help me determine when is a good time to merge this PR” and “Do you have scalability concerns?”. It is meant to directly replace the Champion program, which is a low-traffic program designed with explicit intent to mitigate the effect of blind community merges upon the edx.org site.
I think Slack channels with escalation to edX EMs is a great way forward And I agree with @sarina that the right use of these channels is to support the interesting production relationship between edX.org and non-edX Core Contributors (which I guess includes tCRIL now, right?), and not for general coding help.
That being said, in addition to what @antoviaque has raised already, I think public channels might be logistically easier in the long run. I expect there to be a lot of cross-talk between rooms because of the distributed monolith nature of the platform; eg, some CC “Alice” might have merge rights to only course-discovery, but a change she merged could cause an incident in the LMS, so she’d end up getting invited to both channels anyway. And there’s a good chance that what Alice merged was authored not by her, but by a non-CC teammate “Bob”, who she would want to invite to both channels in order to help resolve the incident. This is based on my experience at edX working across a mixture of Slack channels and workspaces of varying visibility, and finding that someone relevant was almost always being left out of a conversation because they either didn’t know about a channel or hadn’t been invited to it yet.
I concede that I don’t have a solution for the moderation issue, other than having hope that the community would generally respect the channels’ purposes if we made it clear to them.
Just my two cents. I think either way this is a set-up for success, and this decision is something we can revisit down the road if we find that we didn’t choose the ideal visibility at first.
@sarina For the extra work on making the channels public, if you want I’m happy to do it, if that’s possible? Is it a Slack admin thing, a social/asking people thing, both?
For the moderation, maybe we could see if that’s an issue, and figure out an approach when/if it actually ends up being an issue? The principle of premature optimization also often applies to communities We don’t really know yet if there is going to be a need for moderation, while on the other side we know that defaulting to public discussions is an important good practice for open source projects, and one that is often very tempting to leave aside for practical reasons, but bites back.
@antoviaque I am working with a few people at edX. It is a requirement on their side that externally coupled channels be private. Despite being able to make channels that are public on the Open edX side and private on the edX side in the past, we seem to be unable to do this. We’ve spent a few hours on this already, we will endeavor to keep trying.