cEP-0003: Add Community team #45
Conversation
|
Thanks for your contribution! Reviewing pull requests take really a lot of time and we're all volunteers. Please make sure you go through the following check list and complete them all before pinging someone for a review.
As you learn things over your Pull Request please help others on the chat and on PRs to get their stuff right as well! |
|
Sorry I haven't been able to say this during the merging of the original CEP, but I think there are way too many teams. I can easily see some teams being merged into one. Design, Internships, and Management merged into one team known as "Evangelists". I could see that the community breaks away into a separate team in the future. Review is something all orgs related with code have to do themselves. Putting it in a separate team doesn't make sense, as everyone in the review team needs to be aware of every PR and issue opened, which breaks the point of "teams" in the first place. About teaching how to review, I think the Does |
|
I agree. When we can't fill half of the teams, why have so many, that's not really helping, right? |
|
Im particularly against teams like gitlab or cib. I'd rather expect applicants for team leads of the related teams to come up with plans on how to make gitlab/cib better. Those should be defined and ideally be dated so they actually get done. |
|
@SanketDG Merging Design, Internship and Management(which is not a team) does not fit at all in my opinion. Designing UIs, logos websites ... has nothing to do with admin work for GSoC, GCI and such. If Management == Admin team then again, the admin work for servers has nothing to do with design or student supervision. The review team was an idea between lasse and me on a flight, I agree that the team might not work as imagined but again I disagree that the focus of the community team should be teaching review on a higher level than the newcomer process. Though this is just down to the idea/definition of what a community team should do. cib was wished for by @Adrianzatreanu (maybe make an argument for it?) and the PR got merged so I suppose we might want to rework the team proposal process? I agree we might have to further define what the teams' scopes are. I hoped that after we had team leaders for some of the teams, they would work that out for their respective team and we work with that and use it to improve for the next term. What about the idea that the first term is only half a year as a "test term"? Finally I think that the cEP acceptance process needs rework if concerns like this pop up not only after merging but during implementation. |
|
Maybe we could have an |
Yes, I totally agree. But that wasn't the point. The point is to have as many small teams as possible and when these teams scale, segregate them as necessary. Do we have a ready-to-go design team right now? But we could have in the future. "Evangelists" make sense because good design leads to good evangelism, and the GSoC, GCI teams are also responsible for some form of evangelism. And by Management, I mean the Engagement team, since engagement is also closely related to evangelism. The admin teams needs to be separate, I am 100% on that, since some things just need a superuser overlord kind of team. (servers, accounts, repositories)
I would completely blame this on me, for being so inactive within the community for the past few months, and I am sincerely sorry for bringing this up this late.
This is a great idea, and makes sense to merge with the plugins team. I am all okay with having separate teams, but right now, at the very first, 14 teams just does not make sense to me. |
|
As of now based on the efforts required in each area despite the sheer nos. not being there. I think having all these teams works well. Atleast this way each team leader will be able to give a progress report after a month or two on what their team did and we would have an idea of where the focus needs to be. I mean based on the work going on right now each team is necessary even if it consists of 2 members. We can definitely desolve and create new teams.
We need separate teams for these tools right now because all of them require a great deal of work. Teams can be dormant and active. We can though create a I guess an addition to this cEP could be a progress report mechanism which is scheduled every two months or so. This also keeps the team leaders on their tip toes to actually make progress and push people more. If the community is unsatisfied with a team leaders work. I think that is a very important condition to have in the cEP. Now that the realisation of teams draws closer. |
I don't think that you should blame yourself (or anyone). It is not possible to check on everything going on in coala without sacrificing huge parts of you life. This discussion might be a pointer to flaws in our cEP process but cEPs are not set in stone and subject to change and things might just come to light after the merging so in the end I guess this is a perfectly normal situation, just the first of its kind. We'll just use it as a learning experience and improve the process if needed In addition do Udayan I think it is ok to have more focused teams right now. We don't really have the numbers and expertise for bigger scope teams I feel. This leads to existing teams focusing on smaller projects but they will be more effective that way. The whole idea of teams was to make life easier for lasse so he doesn't have to bother with everything anymore. Even if just for small parts, this goal would be achieved I feel. If you have further ideas how to improve teams, lets have a discussion here Should this PR wait until everything is resolved? |
|
@sims1253 can we move the teams to the repo please? |
|
ack e390abb |
|
second ack needed |
|
ack e390abb |
|
@rultor merge |
Order teams alphabetically
Update version