Greetings Eclipse Architecture Council
Hi Wayne, all,
First, I would like to discuss the potential for adding a formal committer training requirement. We already have some
committer training videos, but I'd like to explore options for using a learning platform to deliver a 20-30 minute training session that touches on the important aspects of open collaboration in general, and in the context of Eclipse Foundation governance. The idea being that we use this as an opportunity to ensure that the candidates know what they're signing up for, and what we need from them. Depending on how our discussion goes, I'll open an issue for further discussion.
I think it's a good idea. A learning platform can IMO achieve better results than a video or a text page; so going for such format is IMO a good thing.
I would be careful about making it required too fast. Many of us work in companies with search learning platform and already have to deal with yearly trainings for several topics, and although it makes sense from company POV and no-one challenges the usefulness officially, most people dislike going through those learnings over and over again. They are often perceived as annoying and/or boring. We should avoid creating those kinds of negative emotions too early to new committers, at least not as long as they haven't experienced more positive ones with the community.
But I think it can be a several steps: first having the committer training material using a learning platform, then encourage existing committers to try it (eg by creating a dedicated badge, or a flag on the committer page...), then maybe make it mandatory for project leads, and if there is no resistance, make it mandatory for committers in the 3~6 months after they got elected...
The other topic that I'd like to discuss is the potential introduction of a formal notion of coach into our process. I'm thinking along the lines of an Agile Coach for the project team, but with responsibilities aligned with ensuring that the project team is engaged in good open source development practices. We might argue that this is something that project leads should be doing, but I'm thinking that -- while it might be held by the same individual -- it is a distinct role. This may be something that we consider adding to the EDP. Again, based on our discussion tomorrow, I'll open an issue.
I'm not sold on this idea. In general, I'm not sold on the idea of multiplying roles.
I'm afraid a dedicated role would centralize the OSS governance responsibility on fewer people (the ones with the "OSS Coach" role, which would probably happen to be the same people again: project leads, AC members, PMC members...). The OSS governance is something I believe we all, collectively as OSS community members, have interest to be shared, spread and dis-personalized as much as possible; so we get redundancy, diversity, flexibility... and all the thing that make a project community sustainable. Creating a dedicated role would probably grow the bucket of responsibility for a few people and then reduce the average skillset for other committers.
Cheers,
Mickael
