Membership Model?

Open Source Design meta
1

In past discussions (and both Summits) we discussed about potential membership models to eventually organize decision-making if needed better. While some were fans of the idea and some not, I do think that it’s useful to have a very lightweight membership model, mostly for administrative privileges on various platforms.

I also do think that the Core Team has kind of transformed into this membership model, originally meant as a group of people to handle paperwork and represent OSD in cases where it’s needed (Like Open Source Initative affiliation), I feel like it kind of transcended into a group which steers the direction of where OSD should be going. Hence I think that a membership model with a very low entry level barrier should be introduced and a smaller core group with very few additional privileges (which don’t affect stewardship of the project).

I’d even actually suggest following process:

  1. Convert current core group into membership group
  2. Introduce a membership application process
  3. Vote and set number of people to be part of Core (maybe 5,7 or 9? Currently it’s 11)

What do you think? I realize that one doesn’t want to create too much hierarchy too quick, but if it’s very easy to become a members, I think that we can move forward quicker.

3 Likes
2

For now I’ll not post about my take on it – am interested in others first. :slight_smile: Only for reference, here’s the “Core team” explanatory thread:

1 Like
3
  • I do not mind the core group growing, but we should have transparent rules how one becomes are “core” member.
  • I do not mind hierarchy as long as it follows a clearly defined process and rights and duties.
  • I think it is essential to define what “core” entails, particularly access to domains, site… These are often single points of failure for small to mid size volunteer groups, so we might want to have “due processes” for dealing with them.

Like always: lets fight the Tyranny of Structurelessness

1 Like
4

I am not particularly fond of the idea of membership. I am not sure what’s there for members: what would they gain by becoming one? Right now, there is no barrier to entry of any kind: low or high. One can simply get involved in whatever capacity one finds interesting. I prefer that approach, but it’s just a personal preference.

I have come to accept the existence of the core group as a necessary evil: small decisions need to be made. They are mostly trivial, minor and inconsequential, but all together they somehow influence what we do (e.g. let’s accept the Apache Foundation offer to organise some design content for their next European conference) and how we project ourselves outwards (with this thread being a good example of that).

I think one of the reasons why the core group has worked well so far is because all members did something together before becoming core members, and through that working together they came to know each others’ work style. We found out through practice that we were able to do things collaboratively. I believe that ability to co-operate has been fundamental to our survival so far.

So, in my book, that should be the criteria to join the core group: you should have done something of some significance with us (or with a subset of us), and through that we have come to know that your way of working is compatible with the group’s way of working. Following that criteria, things like giving a talk at a conference where you mention the collective, or engaging with us in social media, do not qualify as doing something significant with us.

Some things that I think do quality as such: get involved in the FOSDEM or FOSSASIA or ApacheCon Europe organising, send patches regularly for the website, review almost every submission that comes into the jobs board, volunteer to spend time in the FOSDEM stand, etc. Those are some things that I have seen people do with us, and I would be delighted to have any of those people in the core group.

But I am wary of opening the core to those with whom none of us have collaborated before, simply because their ways of working may not be compatible with the ways of the group. And note that I say compatible, not identical: people different to us are very welcome, but those differences should not prevent them from productively collaborating with the other members.

Jeez, that was long :slight_smile: Just my 2c, as usual.

5

If we would put aside the definitions or wording of Members or the core group I’d agree with you. My idea of a membership would be basically what Core is already doing. Voting on important strategic decisions and stewardship of OSD. That’s what I’d think Members of OSD should be doing. From what I understand, you define these roles as part of the Core group. So don’t we agree on this then apart the wording? I can understand though why “Member” could look like gatekeeping while the existence of a Core Team can be justified. Although growing +20 people might be not really “Core” anymore. But then again, that’s a matter of wording.

In a nutshell, I think it’s totally fine if we go on like we used to, expand the Core group with a lightweight set of rules to join and stay, have a few people within Core with Superadmin privileges for our services, and establish a process within Core on how we do decision-making. Would this be agreeable with?

6

Yes, I’d say this is good. The main thing I would change/add in Open Source Design core team is to have a set of tags / tasks which everyone can add to themselves about what they are interested in working on, e.g.:

  • coordination
  • event organization
  • job board
  • fundraising
  • forum maintenance
  • outreach
  • etc…
7

and

This is what is defined already in this thread: Open Source Design core team – or not? :slight_smile:

1 Like