Documenting teams and memberships

Basic principles,

1. We are a collective promoting Free Software, and self reliant, private communication infrastructure based on Free Software.
2. Anyone subscribing to these ideas can become an associate member.
3. When two existing members vouch for contributions of an associate member, they may become a full member.
4. Members can form teams to manage free software based infrastructure like wiki, mailing lists, diaspora social network nodes or gitlab code repositories.

Please suggest additions or modifications.

I've a suggestion.Follow the model of old communities where everyone was valued based on merit. This 'two persons vouch' thingy is good for a pirate movement, but it is too formal for a community. A loosely coupled community structure based on meritocracy would be better (that was how FCI worked in the initial stages, wasn't it?)

I dont like the idea of different levels of membership for a hacker community.

@balasankarchelamat but you need two advocates for voting rights in debian as well and it has worked well. Do you not see debian as a hacker community?

In fact, it was the debian structure that inspired me to create this model for pirate communities. It is do-o-cracy, you earn your rights but once you earn it, you get equal rights.

To be very fair, I don't actually care much about the 'voting right' of Debian Developers (and the politics associated with that) so that didn't come into my mind when I initially replied. So, taking back that reply and consider the following a modified reply.

1. Change the goddamn names "associate" and "full". It gives an image of associate members are of less value than full members. Let's invent some other beautiful titles. :)

2. Isn't the concept and planning of 'voting' and all a little premature? I would like to know what all stuff have been decided by a vote in FCI (I joined FCI after it became inactive. :D) and that should help us to decide whether we need to discuss and decide the idea of voting right now.

3. Add another point - No one (not even associate members) needs to get 'permission' to hack on an idea they find interesting. Ask around and if you get someone else to join, start hacking along with them. If you don't get anyone, still start hacking and hope others will get interested and join you.

Unless we clearly state the rights, a few who dominate will eventually become the leaders, from experiences in the past and also from other communities. Its always better to state everyone's rights, so they can demand if it is denied.

Agreed with finding better names, how about we just directly go for a single membership, consider everyone who contribute to Free Software like "associate member"?

I thought so for 6-7 years, but now we got to do it. More than voting, its about documenting. But voting may be required when there is a disagreement or we want to amend the constitution/statement of principles/philosophy, whatever you call it. It is more like a procedure to change something, better spell it out.

Agreed on point 3. Only if there is a disagreement that something is against our principles, we need to stop it.

This is very important for newbies, this would avoid questions like you posed right now (I don't know how things work here, I joined late). When we have things clearly stated, it does not matter when you join.

Also people who already worked together take many things for granted. We know how we manage poddery.com, but what if someone wants to help with maintaining poddery.com? Do we have a document that we can show to anyone who comes with interest to help out?

Yeah. I am all for documentation. :) Let's get others too on this discussion.