Jos, if you write oversimplifications like these ones, you really make it seems you just have an agenda of promoting openSUSE's recruitment system!
As I suspect that was not your intention, I suggest bringing a bit more depth to the discussion.
It is indisputable that "quizzes" (an actual misnomer, as written in the article) and similar joining process tend to be more bureaucratic, one should investigate what are the reasons behind them. For instance, in the case of Debian, the reasons are quite profound and have been covered by an interesting paper by Biella Coleman, called "three ethical moments in Debian" (see e.g. https://lwn.net/Articles/149031/ ).
While you can get rid of most "quizzes" to verify technical abilities (like we've done in Debian, as observer by Ben Hutchings in the comments here), verifying alignment of visions and principles is a tad more tricky.
Posted Sep 6, 2012 9:53 UTC (Thu) by jospoortvliet (subscriber, #33164)
[Link]
Ok, lets discuss. Sorry for the late reply :D
You are basically saying that the test Debian does, besides checking for technical abilities, tries to assess the social side of things: is there a cultural match.
While I understand (and agree with) the need for cultural compatibility between potential joinee and project, I'm not sure a 'test' helps much - if at all. Culture is conveyed and verified in social interactions, not written stuff, tests or bureaucracies. Written stuff can help, that's why organizations like KDE and GNOME and openSUSE and Debian and others have written down their philosophies and point folks there. But it is the day to day work in which you really 'learn the ropes'.
Before you give people commit access to the central repositories, a informal check 'around them' makes most sense - that's how KDE does it, GNOME too I believe. Likewise, openSUSE leaves such decisions to the teams maintaining parts of openSUSE (KDE, GNOME, etc) and we have a git-like branch/merge request system which kind'a negates the need for much more formality. I think that's a good approach: work around formality and bureaucracy in the tools. Once someone learns the tools and works with folks on getting packages in, build up relationships, and those folks around him/her decide to give him/her maintainership access to the shared pool of packages they maintain, I think the 'wider community' or 'project' has no business doubting their technical and cultural fit anymore.
For giving people formal influence, it makes sense to let them give some sign of support of the project philosophy - we let people sign the 'Guiding Principles' before they can join the openSUSE Membership. But we don't "test" their fit anymore, other than looking at their contributions: if you're accepted in the informal community processes, who are we to deny you access to the governance of the project? That would just serve to make the whole project become a stale, immovable, conservative object. Rings any bells?