-
Notifications
You must be signed in to change notification settings - Fork 70
CommComm Membership: Call For Feedback on New Definitions #276
Comments
Again, sorry I couldn't make it today. Anyway, this is pretty much what I had in mind, though indubitably better said than what I could have done 😄 |
One suggestion: might be worth further defining/differentiating a "contributing member" from the "member" you can be nominated to become... Maybe the former could just be called a "contributor"? (Maybe I'm splitting hairs with the definition though. Naming things is hard.) |
Active Contributor --- self-select ---> Collaborator --- nominated ---> Member Need to define: |
@WaleedAshraf So, since Collaborator is essentially a voluntary position, I don't think there should be any time limit for how long they should be waiting. Also, a Collaborator getting nominated to Member refers to the CommComm making an active decision to promote someone, meaning that a minimum duration of being a Collaborator is also unnecessary. |
At what level of collaboration will the CommComm decide to promote a collaborator? |
@codeekage I think this is one of the subjects that still needs to be discussed since these new definitions are still proposals for now, but for my part, I'd stand by what was said in previous meetings: setting hard written requirements probably isn't something we should do, because promoting someone will depend on a great number of variables, starting with the general context. This is one thing that should be decided and appreciated on a case by case basis, IMHO. But I'm not yet a Member, and I'm not taking any decisions or speaking for anyone else except myself, so you know what my word is worth. I may, again, have missed some new things (though today's meeting notes are enlightening). |
It might make sense to be: Active Contributor ---nominated (other collaborators) ---> Collaborator --- nominated (other Members) ---> Member It is always hard to define specific requirements for nomination to either collaborator or member, but I don't think we've had too many cases where people who should have been nominated have not been on the technical side. |
@mhdawson It might probably take forever to transition through being a contributor ---> collaborator ---> member, probably longer than the regular 6 meetings attendance as an observer to become a member. What if contributor should have like some fulfilling task to complete, probably under the evangelism scope labeled "cc-contributors"? with a duration attached to those tasks completes them, becomes a collaborator, attend cc-meetings as an observer would and get nominated for active contributions to becoming a member by cc-members. It going to be fun seeing people finding cc-contributors initiatives or issues and putting in their best to becoming collaborators. |
Sorry all, but I have to disagree, and quite strongly. But anyway, I think that's not the point. We don't especially want to make an easy/short path to become a Member, we want people to get involved where it matters the most: in the initiatives or WG. That's the whole point of the restructuring initiatives and meetings. That and the fact that we already established that making an easy path like the one actually in place wasn't necessarily a good thing. Anyway, I think the path defined here is actually good. It's consistent with the TSC path, and since TSC and CommComm are the two top-level committees, it seems fitting for me. |
@Tiriel Awesome |
Again, I personally am strongly opposed to hard written requirements, for any level of involvement. It feels against the very spirit of what we're trying to accomplish. And it has worked pretty well for the TSC, I'm not sure we should diverge from that. |
@bnb I think this could be a cc-agenda. |
I agree with @Tiriel. We should not impose any arbitrary time limits for "promotion", but rather let the person in question and the team to be promoted to decide on an individual basis. |
I'd like to restate something that I think may have gotten a bit lost here: Community is not easy to define. There are various ways to approach and enable community, and one individual's approach may be exceedingly different than another's approach. One approach is not more correct nor more valid than another approach. Thinking of each of the CommComm's current members, we all care about the broader Node.js community and have our niches within it. Any one of our contributions isn't more or less valuable than any other's contributions - they all help the community achieve the same goals: growth, inclusion, and sustainability. That is also true of any potential future CommComm members, under any kind of membership structure. Scoping out what we think the requirements for membership should be will lead to bringing in more people like us, more people that meet a similar profile to those that are already members rather than being welcoming and open to people contributing to the Node.js Community (capital C) in different ways. Doing so is nearsighted and detrimental to both the Community Committee and the Node.js project in the long run. |
I agree. This question should indeed stay within the scope of our discussions. But I don't think anyone wanted to skip discussing this particular item. To be honest, I feel the topic of the restructuring effort is getting broader every day. But that's a good thing. Things need to be questioned if they are to be improved. And no subject should be scoped out of such an effort, especially when it touches the very core of this committee: the membership. To be clear about my thoughts on the requirements to become "collaborator" or full member: I think we need to define example requirements, some kind of markers, but clearly state that they are not hard requirements and should be adapted to each and every situation. The broader this example list, the better, and it should include examples as diverse as the people in the Community and as different as the ways of contributing to said Community. (I hope I'm making myself clear here, but it sounds weird). Point is, it should reflect the fact that we accept anyone, as long as they have to will to contribute, share, and stay open in this Community. "Come as you are", if you excuse the pun. As always, these are only my two cents on the matter! |
Since a PR has already been opened on that, I'm going to close this issue. But feel free to reopen if there's need! |
In case someone looking for related PR: #294 |
So far, there have been two meetings working toward a much-needed rework of what CommComm membership looks like. We had several members present, but wanted to make sure to make a public discussion to enable every @nodejs/community-committee member to participate.
In the last meeting (that just wrapped up), we came up with two definitions as drafts. We'd like to open up for feedback and see if anyone has things they'd like to add, tweak, or update in these definitions that we may have missed:
I'd also like to add in something that @oe commented on that was impactful to me and helped me understand the direction and process a little bit better:
The text was updated successfully, but these errors were encountered: