I spent time in a bunch of different organizations that worked more or less well. I spent 4 years at the board of a toastmasters club. Another 4 years as part of the moderator of a personal development internet forum. I started the Berlin Quantified Self Meetup and at the moment I’m involved in Wikidata as an administrator.
On the other hand, I don’t see myself as an expert at leadership either.
Wow, that sounds great. Can I poke you for a few questions on how those organizations ran? I think that experience is invaluable.
In particular, I’d like to know how wikidata’s community reaches a consensus, when I imagine many different players would like many different things for the future of the community.
There are cases where Wikidata has ways to find consensus because it has actual policies and there are cases where it doesn’t.
The creation of new properties is for example a process that’s well-defined. At some time a policy was written that a property proposal has to be open for at least 7 days to be created and has to have a majority of support for being created. The person who makes the actual creation decision also has to be either an admin or have the special right of property creator so that not every user can simply go ahead and get a new property created.
On the other hand, there’s a case like interwiki links. Wikidata has different items for the tomato fruit and the tomato plant. A lot of Wikipedias however have only either an article for the tomato fruit or the tomato plant and one Wikipedia article can only be linked to one Wikidata item. All Wikipedia articles have interwiki links to all Wikipedia article in other languages that link to the same.
Various Wikipedia users in small languages care very much about their very short articles having interwiki links to the other Wikipedias. When some Wikipedia articles are linked to the tomato fruit and others to the tomato plant a lot of them won’t have interlinks and as result those users want all articles interlinked to the same article. On the other hand, two taxonomists on Wikidata care very much about linking certain articles to the fruit or the plant and there’s conflict.
Unfortunately, we don’t have a good policy to resolve that conflict and as a result new conflicts about this topic pop up regularly. A way to reduce this problem would be to write an actual policy for how the conflict should be handeled.
When it comes to writing new policy, the idea is to have an Request for Comment (RfC) that declares the new policy and people being able to vote SUPPORT or OPPOSE and when a proposal gets high support an admin can mark it as being accepted after some time has passed. At the moment, the policy about how an RfC gets accepted is more implicit and it would likely be good to have a more formal policy there as well.
I spent time in a bunch of different organizations that worked more or less well. I spent 4 years at the board of a toastmasters club. Another 4 years as part of the moderator of a personal development internet forum. I started the Berlin Quantified Self Meetup and at the moment I’m involved in Wikidata as an administrator.
On the other hand, I don’t see myself as an expert at leadership either.
Wow, that sounds great. Can I poke you for a few questions on how those organizations ran? I think that experience is invaluable.
In particular, I’d like to know how wikidata’s community reaches a consensus, when I imagine many different players would like many different things for the future of the community.
There are cases where Wikidata has ways to find consensus because it has actual policies and there are cases where it doesn’t.
The creation of new properties is for example a process that’s well-defined. At some time a policy was written that a property proposal has to be open for at least 7 days to be created and has to have a majority of support for being created. The person who makes the actual creation decision also has to be either an admin or have the special right of property creator so that not every user can simply go ahead and get a new property created.
On the other hand, there’s a case like interwiki links. Wikidata has different items for the tomato fruit and the tomato plant. A lot of Wikipedias however have only either an article for the tomato fruit or the tomato plant and one Wikipedia article can only be linked to one Wikidata item. All Wikipedia articles have interwiki links to all Wikipedia article in other languages that link to the same.
Various Wikipedia users in small languages care very much about their very short articles having interwiki links to the other Wikipedias. When some Wikipedia articles are linked to the tomato fruit and others to the tomato plant a lot of them won’t have interlinks and as result those users want all articles interlinked to the same article. On the other hand, two taxonomists on Wikidata care very much about linking certain articles to the fruit or the plant and there’s conflict.
Unfortunately, we don’t have a good policy to resolve that conflict and as a result new conflicts about this topic pop up regularly. A way to reduce this problem would be to write an actual policy for how the conflict should be handeled.
When it comes to writing new policy, the idea is to have an Request for Comment (RfC) that declares the new policy and people being able to vote SUPPORT or OPPOSE and when a proposal gets high support an admin can mark it as being accepted after some time has passed. At the moment, the policy about how an RfC gets accepted is more implicit and it would likely be good to have a more formal policy there as well.