Members 1st
This time around the Boosters took on a milestone for the benefit of the Membership Officials team. To explain who they are and what they do we have to look a bit further into the openSUSE Project. Because of its history and relatively young age the project is trying very hard to avoid hierarchies, policies and rules. It emphasizes the creative, a bit chaotic, side of the FOSS ways for openSUSE to get things done, quickly. Everyone that is participating is equal, everyone that is participating is following the same Guiding Principles. The only formal structure is a a group of “Primus inter pares”, that is elected to provide guidance according to the principles: The Board.
But how do you identify who is participating? How do you get affiliated with the project? Who is a member? The Board came up with this definition: Everyone who contributes continued and substantial to the project. As you can imagine there are a million and one ways to contribute to a huge project like ours, so judging if someones contributions are continued and substantial can only be done on a case by case basis. The Membership Officials are tasked by the Board to do this evaluation.
The process to become a member is dead easy. You tell the Membership Officials that you want to be a Member and what you have done so far. They will then evaluate your contributions and vote on your request. Once your request gets more then four positive votes, you’re a Member. If you get four negative votes you get rejected.
Now what’s the problem?
Often when something involves hierarchies, policies and rules it becomes pretty drab, pretty quickly. That was the problem here too, the tooling around this process sucked ass through a straw, pardon my french, and no one wanted to do anything about it. The poor Membership Officials had to use 3 different tools. One for receiving the request (users.o.o), one for evaluation/voting on the request (retro.o.o) and one for handing out the results of the evaluation (an individuals mail client). As you can imagine this made membership voting a tedious task and once one small part of this process changed slightly (the replacement of users.o.o with connect.o.o) the whole house of cards fell apart and membership evaluation came to a grinding halt.
Getting things fixed
Now if something like that happens it’s the perfect milestone for the Boosters. We are all about helping teams and individuals to get their work done! So we started the milestone to get the Membership Officials tooling fixed once and for all.
As the process to become an openSUSE Member starts with joining the Members group at connect.o.o we wanted to bring it to an end there too. Elgg, the social network framework we use for connect, already allowed closed groups that you have to request to join so we agreed that we should just extend this to fit our process. First we added meta data to the request for the requester to explain himself and for the Membership Officials to evaluate. Then we added the voting functionality for the individual request and as last step we created a form including nice templates to email the requester the results of the evaluation.
How the Elgg framework helped
Elgg made this pretty easy because its data model is built on units called entities. A user is an entity. A group is an entity. A join request is an entity and so on. All of these entities are variations of the base class called ElggEntity so for instance the ElggUser class extends the ElggEntity class. Additionally to the entity class there are three helper classes that make it very easy to add new functionality:
- ElggRelationship which expresses (surprise!) relationships between two entities.
- ElggMetadata which is metadata attached to an entitiy, so for instance a tag for a group.
- ElggAnnotation which is metadata attached to an relationship between to entities so for instance a comment from a user to a discussion.
So here is how we were able to implement our membership process in this data model:
Process: The requester fills the contributions field of his profile.
Elgg: A user adds metadata to his entity.
Process: He then requests to join the Members group.
Elgg: A user requests an relationship between his entity and a group entity.
Process: The Membership Officials review the request.
Elgg: The “manage join request” page lists all the user entities and their contribution metadata that requested a relationship to the group entity.
Process: The Membership Officials vote on the request
Elgg: A user entity adds an annotation to the relationship request.
Process: When enough votes accumulated a Membership Official tells the requester that his request was either accepted or rejected.
Elgg: A user entity creates a notification to another user and accepts/rejects the relationship to the group entity.
Conclusion
This was the first major enhancement we did for some basic Elgg functionality and it was very straight forward. We were able to quickly address the problems of the Membership Officials and made it possible for them to work again. Oh, while we were at it we also cleaned up our connect repository, moved all our modifications to plugins and updated connect to a new Elgg version. Pretty nifty right? :-)
What do you think? Let us know here in the comments or contact us on our mailinglist opensuse-boosters@opensuse.org