Wikidata talk:Behavior norms

For now, this page is for discussing how to go about developing policy on norms of behavior on Wikidata.

In the future, it would become a space for discussing those norms.

Looks like discussion has slowed down - would it be time to organize some of these values into a draft policy page? It looks like we have some good basics here, and a draft would help folks to start thinking about what they would like to see in a final version. In the two sections below (Behaviors we would like to encourage/promote and Behaviors we would like to reject on Wikidata) and in Micru’s training draft, we have a very good start.

This would allow more community members to engage and make some more progress. Thoughts?

I agree, and would like to see it happen. Who wants to take a stab at creating a draft policy?

Hello everyone,

Thanks for all the conversation that happened here, indeed, I’m in favor of a policy and read through the conversations here carefully and made a move to create: Wikidata:Behavioral policy (draft) which is like a starting point of the policy. The content of the page was developed all from the discussions here.

It’s open for community deliberation and comments until it’s finally fine for adoption. Thanks

Cheers!

Hello Asaf, thank you for the initiative.

In German WP, and I believe it is similar in other wikis, I have experienced a lack of procedural rules. Also, I have the impression that (a lack of) "problem ownership" is a problem. It is often not sure who is responsible to act. In the end, everybody and nobody is responsible, difficult cases are not dealt with.

Therefore I fully support the idea to have a select committee, similar to an arbitration committee, to come up with more detailed policies, to identify problems and to solve them / ask other admins to solve them.

Thank you for voicing a clear opinion on this. :)

We need some more, of course.

I prefer the scenario where enforcement is done by a specific committee. Mainly because I think this requires a specific set of skills and it is a task that deserves special attention. I think such a committee needs to be selected and held accountable according to a well-designed process, a process that aims to appoint people who are very suited to this work: respectful, balanced and wise individuals, who have broad respect and support from the community at large.

I think they are up to a complex and challenging task, and can imagine they can benefit from professional support, including training, by e.g. an affiliate that wants to specialize in this.

The points about the skills and acountability are very good ones.

Such a committee must not be too bureaucratic, or else it is rendered mostly useless for the function it is supposed to do.

Darwin, could you elaborate on what you mean by bureaucratic? Different people have a different understanding of the word.

+ authority, - procedural stuff

:-) Could you elaborate just a little more? You are against procedures? Against "authority", like in, you don't want rules or outcomes to be binding?

I mean that I prefer a system where admins (or "committee members" - whoever will enforce the policies) have more autonomy, instead of being into a corset of strict rules and policies. From my own experience, it works quite well in Commons, where admins are generally autonomous inside the general limits set in the few fixed rules that exist. Wikipedia (at least my homewiki, wiki.pt), on the other hand, with its many kilometres of rules and policies (in continuous development and growth) is a complete tragedy on that respect, a nightmare. And when an ArbCom was set there, it was so bureaucratic by design that it never ever worked properly, and was eventually shut down some 2 years after it was created.

I feel sorry for your experience on WP.pt. But if rules are not "strict", or if they are "few", doesn't that open the path to arbitrary decisions made on the basis of gut feelings?

It's already on all Wikipedias that owners of extra buttons use them at will and how their feelings are about "normal" (we have them? very surprising this would be: we have no normal users, only some are more normal than others) users. Some of them consider "users" (are actual readers, no contributors) toxic (e.g. your friend Spinster - I've even seen her IRL - and her other friends with "power" buttons to scare editors (is this not a better word than 'users'?) of good faith by no means any intention to poison anything let alone anyone.

I know people who never came back after negative experience of the "buttonFreaks" among admins especially on Dutch Wikipedia where they got the privileges for life since a few years.

To come back to your elephants: we have at least two different kinds 'Indian' and 'African' thousands of miles between them without speaking of "Jumbos" in captivity, in the wild and in fiction.

Could be, but in Commons it does not seem to be a common issue there, at least in my experience. We have autonomy to ban problematic editors, have autonomy to tag a file and delete it immediately, even punctual corrections of actions by other admins generally are not problematic. My experience is that we generally use common practice as a guidance. When problematic situations appear, we deal with them, punctually, in the proper spaces, but new rules are not generated because of that. I hope Wikidata will be much more like Commons than like Wikipedia - a place when one can be working, and occasionally doing administrative actions, peacefully, without too much interaction between editors, and with urgent need reduced to what really is necessary.

And this raises another point: I generally don't care much about the growth of administrative backlogs in Commons, with the exception of obvious copyvios and vandalism. In Wikipedia, for example, one of the main sources of conflict is the (absolutely dispensable) urgency in dealing with deletion requests, making it into a continuous furnace burning newbies, and serving as a stage for wikipolitics. That fake "urgency" in dealing with administrative backlogs in general (something that in Commons most of us just ceased caring for looong, we just do them as time allows) should be avoided here at all costs. Instead, autonomy should be easily given to regular and trustworthy users so that they resolve those administrative problems themselves when they face them, or became aware of them in their usual work here. Then it can be decided if those editors can intervene in more complex situations, or if they are reserved to a more restricted cabinet (but with the same autonomy).

Commons is a little bit different compared to Wikipedia. In Wikipedia, there is only one content for one topic: there is only one article "Elephants". You have to collaborate there if you want to contribute. But in Commons, you can have as many photographs about elephants as you like. This means that there is much more reason for conflict on Wikipedia than on Commons.

In Commons you also only have one "Elephants" category. Inside you can organize it as you want, even with much more freedom than in Wikipedia (which, in theory, would be a cause for conflict, since it's mostly organic, and often missing a proper source). Fact is that conflicts over those issues in Commons are residual, while they are the norm in Wikipedia...

I do not think; there is more between black and white e.g. grey & thousands of colors just as there are more political ideologies between anarchy and a dictature, more than atheism and polytheism, creationism and darwinism etcetera. Stop binary thinking like a computer: not doing this is the excellence of living creatures.

I agree with Darwin; most committees of WMF are way too bureaucratic and stay like that, because the bureaucratic people already chosen keep choosing people like them in the committees so no or few progress, fewer democracy.

+1, let's try not to repeat history, even though that might be pretty hard.

+1 ! (I hate it when a conflict is not solved - or not well solved - just because the people didn't write at the right place, the right person and/or the right time)

+1

There is a good reason why Commons does not have ArbCom, and also why Wikidata should not have one. The reason (one of) is that whereas the number of users is formally huge most of them are not engaged in any activity in the Wikidata namespace. And those who do, the active community, is very small. Pretty much everybody knows everybody. And one just can not have ArbCom in this situation. In addition, it will be very difficult to elect - for the same reason. We need to look for other solutions.

I think this is part of Asaf's point. We are growing beyond the "everybody knows everybody" size. This graph (number of editors with at least 100 edits in the past 30 days) makes that pretty obvious to me. I have no experience with ArbCom so don't have an opinion on it one way or the other. Do you have ideas for alternative ways?

To be clear, let's remember our options are not "ArbCom yes/no". We just need to be thinking about enforcement in general: what do we do -- and who are the "we" who do it, in particular -- about those users who will violate our behavioral norms.

The two broad models I mentioned were: 1. making it all admins' job (and no one's in particular) versus 2. appointing some kind of committee entrusted with enforcing norms and enacting consequences for transgressors.

Within each model, there's plenty of room for process details.

I kept thinking about this and I would like to share my insights based on what you have commented already. I see different aspects about this:

1) the definition of the Wikidata culture: which kind of behaviours we want to see more, and which ones less (this has been addressed already on other threads).

2) the recognition of good/bad behaviour. How can each one appraise actions or comments? We have a "thanks" button which is great to give positive feedback easily, but what about other kind of feedback? And how can we keep track of it as a community?

3) the effect of good/bad behaviour. Here I would like to see more ideas on how to give more influence to those who promote the wellbeing of the community, and how to reduce the weight of those who behave in a way that create a negative atmosphere, so that they reconsider their behaviour. Bans are for extreme cases, are there softer tools that we can use?

I think your point 3 is super relevant and deserves more thinking. I don't have an answer but I'd love to see more thoughts on this.

So it sounds like there's a desire to get more concrete. Some people have brought up (mostly negative) examples from other wikis. I guess we can start collecting in this thread some examples of behaviors we would like to reject on Wikidata.

Please list behaviors you think should be unacceptable on Wikidata. Also, please comment on others' suggestions; if you just agree it should be considered unacceptable on Wikidata, please do express it by posting "+1" in a comment. This would really help gauge community opinion on the various behaviors mentioned.

Please describe the behaviors briefly and generally. The particular anecdote or experience that leads you to suggest this should be unacceptable is not necessary to make the suggestion; if it gets questioned, or people ask for an example, you could share at some greater length. But let's keep it brief and clear to help everyone participate.

Why do you believe that it's not valuable to be concrete?

Well, let us first agree what is the scope of this discussion. There are types of behavior which I hope everybody finds unacceptable, such as personal attacks, POV pushing, removal of reliably sourced relevant data, edit-warring, or vandalism, but these are already covered by existing policies.

What do do with edit-warring resulting from some external conflict (wikipedia editors/anon users changing values for wikidata infoboxes, for example)?

Why consider Wikipedia editors different in a conflict with others?

The situation is entirely different from a conflict happening in Wikidata. The conflict is happening in Wikipedia, they are changing the Wikidata values just to be reflected in the Wikipedia Infobox. What do you do? Will you block them, protect the page? (and risk freezing the Wikidata Infobox in some vandalized state)?

Whatever they do at Wikipedia is for them to resolve. When they troll, when they bring their conflict to Wikidata they do deserve everything we can throw at them. PS there is no such thing as a Wikidata infobox.

Gerard: https://commons.wikimedia.org/wiki/Template:Wikidata_Infobox

Infoboxes that gather their values from Wikidata are also generally known as "Wikidata Infoboxes" in Wikipedia.

it only shows that there is somewhere an infobox by that name. It is not a Wikidata infobox.

I was referring to those infoboxes (generally known as "wikidata infoboxes") in my comment above. In any case, there must be some procedure to follow when that happens (kind of a proxy edit-war)

I suppose Darwin means that properties and/or items here are used in other project's infoboxes - most likely Wikipedia.

Yes, exactly.

There are 280+ Wikipedias so giving each and every one a special status is a bit off. Wikidata is not exclusively used by them either.. Everybody has to behave including Wikipedians

I don't think "edit-warring" is well covered by the current policy. We lack a policy about how to go about resolving the conflicts and that specifies exactly when "edit-warring" begins.

Wiki-Hounding: https://en.wikipedia.org/wiki/Wikipedia:Harassment#Wikihounding

I would +1 this, and any type of behavior that falls under harassment (let's define this together) and makes people feel personally uncomfortable.

+1

+1

+1

+1

Blunt reverts of good-faith edits by experienced community members, without giving a decent explanation.

+1 and more generally all the "no-answer/silent" attitude which is not really compatible with a collaborative projects and only escalate conflicts.

That said, could you give details of what you expect as a « decent explanation »? I revert *a lot* of edits who are probably not intended as malicious; most of the time, I just use the Edit summary and often, the reason is kind of obvious (to me, but how can I know if it's clear to the person I revert?) so I just left a 1-3 words explanation (like "Self-referencing", "Wrong language" for label/description).

+1 (and it should be possible to give some explanation in the summary when we are removing some value or property which can be controversial)

There are no summaries in most of the case, so that this is not possible. Going to a user talk page for every revert is an overkill.

DarwIn, Ymblanter: that is why I revert a lot. I prefer a revert (which is a bit rough but allows to leave a summary) than just a simple removal. Plus, with revert, at the very least you have a notification. Should we encourage this approach or not?

I hate those revert notifications, they are like a red warning that a conflict is coming, and cause anguish only by looking at them. Frankly, I would prefer to not be notified at all, and finding out what happened on my own sometime in the future... Specially when it's not controversial.

I understand but you can personally choose to ignore some messages (including but not limited to notification), meanwhile, there is no solution (that I know of) to aknowledge the situation if no message is left. The choice has to be done on the receiving end, no?

My position is that it's always better to commmicate too much than too little (given - obviously - that the amount of messages is reasonable and not spamming, which can be an other painfull problem, probably worth opening an other section on this page to deal with).

Yes, I can ignore them, but I'm too curious for that xD I concur that it's better to explain things in a reversion than not explaining them at all. I would prefer, however, if it was possible to do that using the summary, like in Commons and Wikipedia

Maybe I'm missing something but if you are reverting, it is already possible to leave a summary (in fact, it's one of the only case where summary is available on Wikdiata). No?

Ah yes, the conversation did a full circle. We started talking about this because no summaries are allowed in Wikidata except in reversions, and then you said that you preferred reverting than removing because you could then justify your action. But it would be better if we could justify it in any action we may do in Wikidata, not only in reverts, I believe.

+1

+1

Yes indeed, but I'm pragmatical and I'm working with the tool we already have ;)

You can switch them off. This is what I did a year ago.

Probably I should, but it's like a love/hate relation.... But the proper way of explaining the stuff we are doing should be by normally adding a summary, like you said.

+1 on Ymblanter remark. I miss the possibility of adding a personalized summary in the regular actions we do at Wikidata, which often require some additional explanation (and can lead to eventual conflicts, or at least dispensable interactions)

I disagree that we should discourage blunt reverts without explanations. When there's an edit that appears to be a very obvious mistake (typically made by an automated tool), and one can often assume that if the original author were to see it for more than a moment they would agree it should be reverted, it doesn't always make sense to take the time to explain it. If somehow the revert was incorrect (or not immediately understood/agreed upon), the original author can re-revert (with or without edit summary/comment) and a discussion can start. When human involvement is absent for the original edit, I think we can have a workflow of edit -> revert -> re-revert and discuss.

A typical case here is vandalism. I think on enwiki and other wikis, reverts/rollbacks etc can be performed on really bad edits or vandalism edits without any explanation (because it's obvious). Also, this is making me think about the `rollback` userright (Wikidata:User access levels#Rollback), which is typical for this case as a rollback is a revert doesn't have any explanation.

But since not everyone has rollback rights by default, an undo without explanation fits this case.

the weaponization of obvious is by now plain. editors re-reverting a bot can expect to be blocked by the admin bot operator, who programs the bot for their own obvious POV not consensus. admins do not collaborate, explain, nor apologize because they do not have to.

I think the idea is not as much « discourage lack of explanations » but more « encourage to leave explanation », in order to start a dialog more early.

obvious and often can be very subjective (especially in a multilingual context) and by me experience, two reverts leads to escalating edit wars more. The first person reverting has the opportunity to leave a summary and it should be used (except maybe for very very obvious mistakes, but even then I prefer to leave a short summary which doesn't take much time and can save a lot of time by avoiding conflict).

Yes, sometimes it is perfectly acceptable to revert without an explanation, when it's some consensual revert (I do it all the time with good old CommonsDelinker). With obvious mistakes it's the same thing. I guess good sense generally applies to all that. :)

So, do we want to rephrase that in a "positive way"? Such as: "Try always to give an explanation when you do an edit revert, especially if it applies to a very sensitive topic".

That "always" there doesn't look good. :P

Maybe "Try to give an explanation when you do an edit revert, especially if it applies to a very sensitive topic"?

+1 happens already too much on Wikipedias - reverting edits is too easy: not providing one or more arguments is a huge "nono", especially some admins with their "power buttons" think they are always right, knowing all the grammar and political policy rules forgetting we are creating together an amazing encyclopedia based on 5 simple rules of thumb they are supposed to understand better than us "normal editors" (define 'normal'). They forget one of the most important and very easy to apply: assume good faith.

yes, i see a lot of "obvious" reverting without any interaction other than templates on talk elsewhere. and when discussion begins about admin behavior, then radio silence.

that would be something to reject

+1

Overconfidence? I'm not quite sure how to express this, but a handful of cases of large-scale problematic edits/conflicts I've seen that have been tricky to resolve have involved editors who seemed to be certain that their way was right, and everybody else wrong. Most of these people seem to end up banned or otherwise persuaded to leave, but that seems maybe the wrong way to resolve these things. We want to encourage people to listen to others, to work collaboratively rather than idiosyncratically; these editors typically come in with a lot of energy for whatever it is they want to focus on; if that could be redirected to actually helpful purposes that could be a big win for us. But I'm not sure what structure would actually help accomplish that...

I would call it: "consider that you might be partially wrong and partially right". Truth can only materialize when all the views are considered and integrated.

It would be also nice to remind people that we are humans like them, so we all have partial knowledge, and we are subjective individuals. We can try to better ourselves, but they should do that too. Only when both people have removed their biases, then it is easier to find consensus.

That's an ooold old issue... I obviously support integration vs. ban of those editors, but it often requires a lot of time and dedication from the mediators, as well as a community prone to tolerance and reintegration, which often is not the case. No idea how is the community here in Wikidata on that respect. But in my own experience, the main obstacle to this is the time and dedication it requires from a third party in order for it to be accomplished. :\

the main obstacle is a reliance of technical tools to finish conflict, and assert control. inability & disinclination to actually collaborate: why waste time talking when you can drop the block hammer.

It's all about right arguments; (ab)using powerButtons like blockUser needs thorough explanation(s) why. There are five rules applicable: one or more (or the law) should be violated before "punishing" a fellow editor of good faith.

Yes, it takes time and effort, for sure. And perhaps not so rewarding as watching your edit count go up.

Not rewarding in general. It's not only the time and patience we invest. As there is often a need of a compromise between a number of parties, the moderator risks being seen as the enemy by all of them, and attract bad interactions upon himself. Editcountitis has nothing to do with that, it's obviously much more secure and rewarding to go about your own business and let them eat each other alive in some corner of the project. Been there, seen that, got the T-shirt...

Personally I find extremelly difficult to mediate on wiki, where there are no cues about what the involved people are going through. I think any serious attempt to resolve conflict should involve at least real-time communication.

My experience is that real-time communication involves far more misunderstandings, and such discussions get heated a lot more easily than on-wiki ones. It's easier for people to make themselves understood when they can take however long they want to write up their post.

We had different experiences, then. However I also have observed that people who come to the wiki prefer to stay on wiki, as if they had fear to reveal their face. So we'll have to get used to that.

I couldn't agree more. The most successful mediation I've done was with two well established editors which diverged on the way of writing indigenous words, mostly about Brazilian ethnies. They already had a considerable block log, and were constantly at the admin board, and would remain there fighting for days or weeks till they would be blocked again. I was a friend of both of them on Facebook, and I knew they were not as stubborn as they looked onwiki, so I privately arranged for a truce there, before officializing it onwiki. The wars stopped immediately, and apparently any conflict was afterwards dealt with privately on FB in a much more civilized manner - to the point that eventually one year after the truce they meet each other at a wikimeeting, and became friends, till today (that was in 2010/2011). My own experience is that offwiki interaction is generally more healthy, productive and constructive than onwiki, specially in wikimeetings and offwiki activities. However, I also have direct knowledge of instances where offwiki platforms were used for harassment and even blackmail, so some caution must be used.

What I find is that there is a distinct difference in the item centred approach of Wikipedians and the more collection centred approach of people like myself. When you talk about concepts like so many concepts like "living person", they gain a completely different perspective. My problem with the "Wikipedia" approach is that they deny even the existence and the relevance of this perspective.

This is clear in the way that I work. Edits in my "scholarly work" are about persons, but in the background every change to a person triggers one hundred more edits in a batch job. I truly do not care for any of these persons as a person, they are authors of papers, co-author of others.

It is just one example. My problem with Wikipedians is that they typically are very defensive about their project do not reflect at all how we can benefit each other and consequently I have in return little to no time for the standard Wikipedia arguments and points of view.

Ok, so just like I tried to do with positive behaviours, I'll try to sum up also the negative behaviours.

1. Do NOT engage in personal attacks, harassing, threatening, stalking, outing, doxxing, etc. of other contributors. There is no excuse for this, so don't do it.
2. No vandalisms. Do NOT engage in deliberate attempts to damage or compromise the integrity of Wikidata and/or its data.
3. Do not use bad data and/or sources to deliberately push your point of view or to hurt Wikimedia projects. Remember that Wikidata has the possibility of hosting data acknowledged to be false or wrong, provided that such statement is marked as "deprecated". Failing to mark false/wrong data as such can be considered a vandalism, and treated as such.
4. No narcissism. The fact that you think you are right doesn't make you right. Instead, try to listen to others and to work collaboratively, rather than idiosyncratically.

Of course, you're welcome to comment and suggest, as with the others.

I don't like that the first point groups personal attacks together with those other issues. Harassing, stalking, outing, doxxing, etc are not personal attacks, and personal attacks are not any of those. Both are very problematic, and the risk of conflating them is the risk that personal attacks become tolerated. We should be making the distinction significant, by either not grouping personal attacks with these other behaviours or by explaining what a personal attack is in the immediate context..

Well, « Harassing, stalking, outing, doxxing, » is related to person(s), so it is personnal, and it's a kind of attack ; but I get your idea, it's maybe not a "personal attack" as defined on wikis. Anyway, I find logical to group this item together. Maybe we can rephrase it like this :

• Do NOT engage in personal attacks, harassing, threatening, stalking, outing, doxxing, etc. of other contributors. There is no excuse for this, so don't do it.

+1

Ok, corrected.

@VIGNERON: +1.

What ArthurPSmith mentioned is also important. Maybe I would phrase it like "No narcissism. Just because you think you are right, that doesn't make you right. We want to encourage people to listen to others, to work collaboratively rather than idiosyncratically."

Thank you Micru, I integrated this into the draft.

Based on the discussion here I have created the first draft: Wikidata:Community behavior training

I have added some points, and expanded others.

The idea is to have an open process where everyone can participate in creating a better community. Instead of having a committee, the community can participate in a similar way as we do in the property creation process.

I have purposefully avoided the terms "norm", or "policy" because I have the impression that the community wants each one to take responsibility to better themselves, as opposed to force people to conform to norms.

This is excellent, thanks! Two comments:

1. "gather knowledge about yourself" seems a little clunky - "learn from your mistakes", "listen to yourself" maybe?
2. "the talk page" - it may not be clear what is being referred to here (and this sounds like a "wikipedia" comment not a "wikidata" one) - can we be more specific about item talk pages, wikiproject talk pages, and project chat (when to go to each)?

But definitely a great start.

Happy to hear your feedback! Regarding your comments:

1. Changed to "listen to your needs".
2. The idea I had in mind is that the talk page of "Wikidata:Community behavior training" is used as a central discussion page for discussing behavior related topics. I changed "the talk page" to "this talk page" (+wikilink) to be more specific.

+1 to this type of page. Maybe the style of headlines could be more like an FAQ (e.g., "Content disagreements" might be expanded into "How to handle content disagreements" or even "What should I do if I disagree about some Wikidata content?"). In general, most headlines are not speaking very much to the new reader (if you put a link to this page on a new user's talk page, it needs to be clearly addressed towards their first needs or they will just ignore it). For example, a newbie is probably not interested in "Community building" yet but might read a section on "How to work together with us".

Also, I wondered if we have any page where the all basic situations in editing work are explained (What if I find a duplicate? What if my edit gets reverted? etc. Especially fresh users may not know how to dig up "the concerned editor" from the history at all, so it would be good to link to pages that explain such things when giving such advice). Our existing documentation is not short but the FAQ is not easy to use and rather partial. Moreover, much documentation is written with the solution rather than the original problem in mind (e.g., the FAQ includes "How do I merge two items?" but does not mention the word "duplicate"). Maybe this is off-topic here, but the behavioural documentation eventually needs to be integrated and aligned with the other usage documentation.

Hey Micru, well done on putting together this draft. The concept of training new community members to ease their entry into Wikidata is awesome. This would be a very helpful page for someone starting their Wikidata work.

We should probably look at training and policy as two supporting, but diffierent things. Training sets people up for success, but policy helps the community when things don’t go as hoped. I assume the training in the draft is intended to be voluntary; conscientious folks will make use of it, but others won’t.

When conflict arises, it will be difficult to point to a training page to resolve the conflict.  A contributor could fairly say that they did not realize the behaviour there was required, only suggested.

Hey Patrick, where did you get from that the training was supposed to be for new community members? The training is for everyone, new and old members without exception. Participating in Wikidata implies participating in the community behavior training. This can be stated in those words if you think they would bring clarity.

Training is as voluntary as wanting to participate in this community. By participating in Wikidata, you would commit to participate in the training either implicitly by interacting with other community members, or explicitly by being summoned into that talk page.

Of course we do not want (or at least I do not want) "to point to a training page to resolve the conflict". That is a mindset that requires policing, judging, and punishing, which is the way Wikipedia does it, but it doesn't need to be the same here.

I also want to remind you that Wikidata is a low conflict zone. We don't have that many reasons to be angry at each other, and when we do I think that it is more healthy when we talk things through, and we find a way out that is more helpful than just banning, if possible. Extreme cases are always easier to deal with than more subtle ones, and for that the less policies, the better. Of course if some negative behavior pattern comes up frequently, then we can foresee a standard response to that.

Intrinsic good behavior can only be encouraged, and if a user does not follow this encouragement it is not always clear what to do. It depends on their track record, on their willingness to listen and improve, and on what the community can come up with for their particular case.

Hey Micru, thanks for the clarification. I should emphasize that I really, really support this idea, and do see the value in it. I didn’t mean to sound critical.

I agree that Wikidata is currently a low conflict zone, and that is remarkable by Wikimedia standards ;) I think your approach could cement some of the good practices that Wikidata contributors have developed.

The point I was trying to make is the same that Asaf made in his initial post on this topic - as the project grows, conflict will likely grow too. I’m not sure that Wikidata will be able to stay mostly immune to the spam, the POV-pushing, and tendentious editing that other large projects see. Training will be effective for the people who are here for the right reasons. Policy helps when people come for reasons that don’t align with the mission.

Hey Patrick, I appreciate your feedback and I would love to take it into consideration. However, I have decided to no longer work on this on my own. I have the impression that writing this text should be a collaborative effort, and for this reason I prefer to no longer be involved as an individual contributor.

If there would be a task force created to such effect, I would consider joining. Of course, I would welcome other collaborative efforts to write this text (RfCs, more discussion, etc).

Norm aren't the same thing as policy. Norms in a community get created by conflicts being resolved. It feels to me that there are conflicts where we currently lack an effective way to resolve them.

Having an institution like enwiki's arbcom that can bring a conflict to a resolution would be valuable.

Yeah I think your observation is right. We don't have good processes/institutions/... to resolve conflicts. I only have experience with a group like you mention in a group outside Wikimedia and the result is so-so. What are people's experiences in Wikimedia?

+1

We on nlwiki have an AtbCom as well; unfortunately they are necessary as judges are necessary in the real world. Sometimes they make contraproductive decisions tlike blocking people from subjects, name spaces etc

Following up on @Ijon's call for behaviors we would like to reject on Wikidata... Can we also think of positive behaviors that we explicitly want to encourage?

Copying the instructions from the previous thread:

Please list behaviors you think should be promoted on Wikidata. Also, please comment on others' suggestions; if you just agree it should be considered good practice on Wikidata, please do express it by posting "+1" in a comment. This would really help gauge community opinion on the various behaviors mentioned.

Please describe the behaviors briefly and generally. The particular anecdote or experience that leads you to suggest this should be encouraged is not necessary to make the suggestion; if it gets questioned, or people ask for an example, you could share at some greater length. But let's keep it brief and clear to help everyone participate.

I'll start with a practice I could be better at myself 😉:

Wikidata is a community. Engage in conversations with Wikidata community members. Find WikiProjects relevant to the topic you work in, and use on-wiki channels like talk pages and the Project chat to actively engage with other Wikidata editors.

Ask questions. There are no stupid questions.

+100 :)

+1

+1.

+1

+1

Feedback, even if it's negative, is a gift. When you receive negative feedback, don't be discouraged. Take it seriously, take some time to read through it, understand the point of view of who provided the feedback. It will help you to make your own work better!

Explain your reasoning while reverting someone. (don't know how to do it when the contested thing is removed, rather than reverted, though)

Indeed. This seems like a potential feature gap. @Lydia Pintscher (WMDE) - is it part of the UX thinking to possibly allow an optional edit summary in removals?

Yeah I've been thinking how to do this while maintaining the ability for people who don't speak English to read the text. https://phabricator.wikimedia.org/T47224 has some work on it. Additions/comments welcome.

Item talk pages are rarely used, but I think they could be a helpful resource in communicating about the reasoning behind edits. Can we encourage this?

+1. (Also, can we have a system for including on a Wikiproject page a feed of recently-edit talk pages related to the Wikiproject?)

+1

Talk pages are generally a drag, so if things could be easily explained without recurring to them (such as the initial reasoning behind some given edit), that's much better. If some kind of controversy arises, then we go to the talk pages and solve it there.

Also some action that is reasonably expected to cause controversy should ideally be better explained in talk pages, to avoid misunderstandings.

+1

Assume good faith.

I've seen Wikidata users go to some pretty extreme degrees on this, and have it turn out that it was quite necessary. For example, we often have situations where to User1 it appears that User2 has been adding statements that look like outright vandalism ("this organization is an instance of a shish kebab!") and later it turns out that the item's label had been vandalized earlier in User1's language, and the additions were completely correct. Or two items had been accidentally merged and the users thought they were for entirely different topics. Or a certain property's label and description are unclear and have incorrect implications in some language. Or during a discussion one of the users miscommunicated something because of the language barrier. Also, some people here are often used to norms from another project, and make mistakes as a result.

Wikidata's users are actually very good at this from what I've seen. Still, it's important to emphasize that this project really needs this principle.

+1

@Yair rand, it sounds like "things may not always be as they appear" :) But yes AGF is always good.

Ok, so we have already a list of these "positive behaviours", I'll try to render them in a way that could be easily reused for the "final policy".

1. Assume good faith. We're are all committed to help the project.
2. Engage in conversations with Wikidata community members. Find WikiProjects relevant to the topic you work in, and use on-wiki channels like talk pages and the Project chat to actively engage with other Wikidata editors. Or, if you feel more like it, give the Telegram channel a try.
3. Ask questions. There is no such thing as a "stupid question".
4. Answer to questions someone else asks you. Take some time to help other users, especially if they overcame their shyness in asking. If you don't know the answer, a simple "I don't know" is always better than no reply at all!
5. Diversity is a plus. We are a diverse community, with people contributing from all corners of the world. Take some time to consider that a divergence is not necessarily a source for conflict, but a way to expand consensus.
6. Feedback, even if it's negative, is a gift. When you receive negative feedback, don't be discouraged. Take it seriously, take some time to read through it, understand the point of view of who provided the feedback, maybe ask for clarifications. It will help you to make your own work better!
7. Try to explain an edit revert. Especially when you revert an edit on a sensitive item, please explain your reasoning to the user and try to remember that Wikidata has the possibility of hosting conflicting data, provided that each statement has at least one reliable source.

Of course, please comment and suggest, this is my take to the question, even though I stole most of your lines to provide comments. :)

I would add something about giving feedback to others. The way you wrote it seems that it is only about receiving feedback, but contributors should be encouraged to give feedback as well, that is how we can know what we can improve in ourselves or what we are doing well already.

Also some users seem to be sparse in their communication, as if they would expect what others to know what they think. I don't know how to phrase it... maybe "make an effort to be understood"? Or "assume ignorance"?

And I would mention something about participating on the offwiki channels as well, even if it is just for fun :)

Oh, and yet another thing to add. "Answer questions, specially if they are addressed to you. If you don't know the answer, a simple 'I don't know' is always better than no reply at all"

Thank you, I integrated all your comments - or at least I tried. :)

I'm a bit worried about "Feedback, even if it's negative, is a gift.". Though generally correct, I can see this being used as an excuse to harass users and claim to be gifting them.

Good point.Would it be useful if we would write a guide on how to give feedback?

I really like the model for the Technical engagement team for social norms. Some of it is not applicable in Wikidata, and volunteer engagement is a lot different than professional expectations. But we should have examples of non-acceptable and encouraged behavior

Nice. Still don't like that "always", though. While reverting obvious vandalism or certain automated bot editions the effort of giving any explanation about it is worthless.

Stricken out.

@Sannita's comment seems to be quite close to what w:en:Wikipedia:Dispute resolution says, although obviously the enwiki policy is much lengthier. Some things from there that could be useful:

• Don't lose your temper, and don't treat disputes as battles to be won
• Disengage – most disputes aren't very important, so if you're embroiled in one, consider if you want to take a break, and think about the dispute with a long-term view (the enwiki policy says it better)
• If you think another editor is behaving inappropriately towards you or someone else (e.g. making personal attacks, being aggressive or being disparaging), you should try to resolve this on their talk page, and then go to Wikidata:Administrators' noticeboard to discuss their behaviour if that fails to resolve the issue [we already have two civility-related policies, but neither of them say something like this]
• If you think another editor is abusing multiple accounts, file an investigation request at m:Steward requests/CheckUser [we already have a relevant policy but this could be worth mentioning]

The policy also deals with things for which Wikidata doesn't have a counterpart:

• The English Wikipedia also has community sanctions. I do remember there was an interaction ban imposed but formalizing such a process (for topic bans and the like) might be desirable, even if it doesn't need to be used much.
• Wikidata doesn't have an arbitration committee or a functionaries' mailing list, so any mention of revision suppression (oversighting), outing, harassment, and serious conduct issues would have to be referred to the administrators' noticeboard, the oversighters or the appropriate WMDE/WMF staff members.
• Wikidata only has one administrators' noticeboard.
• Wikidata does not have a username policy.

(Notifying Micru, from this discussion.)

Also, I might want to promote RfCs as a way of achieving a consensus, since a lot of important discussions (especially on the project chat) seem to fizzle out without the actual problem being resolved.

+1

Issues do not achieve consensus just by opening an RfC, they need active work to find out what people want, adapting the narrative so that more voices see themselves represented, and bring it up again and again until it can be accepted. If there is not enough motivation capital to drive a discussion forward, then it is a fair resolution that it fizzles out. Motivation is a scarce resource so it has to be used wisely.

yeah, i would say model RfC as a venue for facilitation of what consensus is, and produce compromise solutions. it all too often is used to push a minority view, and the community if polarized is not committed to produce a compromise outcome resulting in constant impasses

we should have a norm of thanks and positive feedback for good, work, cool comments, and fixing ontologies

+1

+1

My feeling is that while the most important thing here is obviously culture, common decency, etc., there is also quite a bit that that can be done "by the machine". Three things that I would love to see in this department:

- When reverting an edit it should be mandatory to state a reason, perhaps selecting from a preset list with an option of free-text.

- following up on my first point, it should be possible to flag (perceived) vandalism using a check-box or similar, it's too important to be left to an optional text comment

- changing an existing statement without also changing the reference should trigger a warning.

I apologize if this comes off as an attempt to de-rail but that is truly not my intention - having your edits reverted is something that most newcomers will experience and it can sting - it's important how we handle it. Being told by the UX can perhaps feel less intimidating than being told off by your (more experienced) peers. Just a thought.

It should be possible as well to explain why we are removing or changing something. Yesterday I removed the upper limit of "mannerism" which was 1580, as in Portugal it extended well into the 17th century. There should be an easier way to explain why one is doing that, besides opening a topic in the talk page... And before someone talks about references, I don't know how to use a reference that *disproves* what is written there (such as talking about a mannerist work produced in the late 17th century)

I've often noticed cases of your third item - maybe by default references should be REMOVED if a statement is changed, unless you check a box or something?

Removing references sounds like losing valuable data (because it would be difficult to realize that somewhere in the history there was a reference for a previous value). Perhaps some kind of "deprecated?" or "possibly un-matching" tag could be stuck on the reference, and/or it could be grayed-out.

But that's rather off-topic for this conversation, which is to be about norms of behavior, so let's develop this elsewhere.

I'd love people's input on https://phabricator.wikimedia.org/T76232.

Not a bad idea, I would support that👍 As it stands, one can change the claim to anything and have it supported by a previous reference. If it's not caught right away - when the reference is in a language you don't understand you may hesitate to challenge it - it quickly becomes "fact" and very hard to catch.

What about adding some hints about how to communicate without violence? For instance:

1. Make factual observations: do not judge actions, just describe them.
2. Explain the impact it had on you: if something makes you happy, angry, sad..., then say so, but only if it is genuine. Bonus points if you can explain the reason.
3. Say what you need: people are generally more open to help if they can understand your motivations.
4. Make requests, not demands: nothing must be done, however if it makes life better we might do it.

Anything else?

I like the approach of offering advice (that is consulted when users want to learn about the ways of the Wikidata community) rather than just setting up rules (that are only looked up in a conflict to find legal support for one's position). It would be a worthwhile activity to build "training materials" that help contributors to become experts in dealing with other people, both on a small scale (e.g., in a dispute with another user) and on a big scale (e.g., in implementing some major restructuring effort that needs to be coordinated with other communities). People with such skills can get others to work more effectively together. It would be good to have many community members who view this as their main challenge, without pursuing any content-related agenda themselves.

The main question might be how to make contributors read such advice in the first place, since few people will actively search for this. The hints would need to be presented in a form that is easy to digest and immediately useful. Many of the hints would not need to have the status of a community policy -- they can come as tips on how to lead successful discussions that don't escalate into aggressive interactions that waste everyone's time. One could also give examples of conflicts and their solution to prepare users for certain patterns that might trigger aggression or frustration. I think most people could benefit a lot by learning about how to communicate (online), and this will help them in their lives beyond their Wikidata work, but it can be a touchy issue since people usually do not want to be schooled on how to talk properly (especially when they think they were wronged by someone else).

The community members interested in honing their social and political skills could show up if the tasks that we create are rewarding and safe enough, which is not easy. Sometimes I watch with stupefaction how in the Wikimedia movement power structures are created that backfire with stress and attrition to people participating in them, luckily we can learn from past experiences and try to improve upon them. I think that if we create the necessary conditions for participants to grow personally with the project, the rest (training materials, a legitimacy framework) will follow naturally.

Contributors might not be interested in reading advice, however they should feel the effects from the people who take it to heart. I agree that anyone working on Wikidata can use their skills beyond the project, basically because when we solve issues between ourselves we can (with enough effort and dedication) push those changes into the world, or just approach our daily lives differently. However, I am still skeptical about the written medium to have difficult conversations, because communication is normally embodied and physical presence is still what drives the world.

What does "violence" mean in this context? This is an online project... (I assume this is an alternate sense of the word that I'm not familiar with, but the dictionary isn't helping.)

Quoting from this website:

"If "violent" means acting in ways that result in harm, then much of how we communicate — with moralistic judgments, evaluations, criticisms, demands, coercion, or labels of "right" versus "wrong" — could indeed be called violent."

"Unaware of the impact, we judge, label, criticize, command, demand, threaten, blame, accuse and ridicule. Speaking and thinking in these ways often leads to inner wounds, which in turn often evolve into depression, anger or physical violence."

"Sadly, many of the world's cultures teach these "violent" methods of communication as normal and useful, so many of us find our communication efforts painful and distressed, but we don't know why."

The way I see it is that communication becomes violent as soon as a person wants to impose their will, or prevent others from imposing theirs, using language as a conceptual weapon. Most of the time it happens subconsciously, because the person doesn't know how to communicate in a way that their views are taken into consideration, or they do not understand how consensus-making works or how they can fit into it. Other times it happens because the views of a group splits, and they feel attacked by decisions or positions they cannot understand, and retaliate the only way they know or have available.

Conflict is inevitable, because things rarely go the way we would like them to go. However, regardless of the outcome, it is always more positive for the community if said conflict brings more mutual understanding by communicating in a nonviolent way. On Youtube there are several videos about "nonviolent communication" that are quite illustrative.

Thanks for starting this conversation. I also agree that it is properly better to start with these policies now, and discuss and agree on them calmly, then get into an actual problem and then create policies in the heat of the moment.

Three things come to my mind when I think of Wikidata and community behavior:

1) Although I hear the community being called out a lot for how awesome we are - and I think the community is pretty awesome - I am repeatedly negatively surprised by the tone in the Project Chat and some discussions. Often these are specific contributors in their discussions to each other that have a harsher tone. I am not particularly fond of this harshness, and would prefer if we all get friendlier - but at the same time I certainly don't want to see a tone police being set up. I try to be a positive example in my interactions.

2) In general, because Wikidata is more about structured data than about prose text, a lot of nuance is lost in Wikidata in the first place, which reduces the area to attach controversies to quite a bit. The discussions, when they get heated, are rarely on the level of single items, but rather on a higher level, such as the usage of a specific dataset, or what a property means. It might be that due to the loss of nuance we need, in general, less rules per contributor than we need on most Wikipedias, and maybe less bureaucracy in comparison to other wiki projects. I think that is a good thing, and that tends to put me in the "fluid enforcement" of rules instead of the "strict and organized" camp. This also because I don't want to burden anyone with such a role.

3) Also, our edit in the content namespaces to edits in the other namespaces ratio skews much more towards the content namespaces than it does in many other wiki projects. Which I find is great. I call this the do / meta ratio. This also leads to less conflicts, which is neat. I think this also comes from the fact that we have people collaborating across languages without understanding each other - and without the need to do so. This works a lot of the times.

So, I think that kinda tells us why we got so far and so big without having behavioral norms being instituted already. But we will need some rules, and I am super thankful for having this conversation started.

Regarding where to take the rules form or if we should implement it ourselves: as discussed above, our do / meta ratio skews heavily towards do. This means we don't have that many resources that we are spending on meta and creating such rules. Which is why I pragmatically think that stealin/d/d/d/d/d-adapting rules form other communities is the way to go. Just because we are lazy and we really don't want to discuss and put the effort into creating our own rules. But if anyone wants to actually commit to the effort of creating our own rules, sure, go ahead!

So here are a few behaviors I think should be covered, and are partially already covered:

- no stalking, outing, doxxing, attacking, harassing, threatening, etc. of other contributors.

- remember that contributors are common humans. Remember that we are all doing this in order to benefit humanity. We don't want to burn our fellow contributors, we don't want to intentionally anger them, distress them, annoy them.

- remember that our contributors might be very diverse. A project like Wikidata may find people who are very different from each other being interested in contributing. These people, us, might have very diverse backgrounds, with regards to where we come from, who we are, what we believe, how we think, what interests us, what motivates us, and what discourages us in the many forms of discouragement, from demotivation to anger. Let us not assume that all of us are like ourselves, and let us not build barriers towards collaboration for those that are different. Abusing these differences for attacks or harassment should not be allowed.

- if bots and humans get into a 'fight', humans should have an advantage. Using a bot to inconsiderately overwrite human contributions, particularly repeated human statements, should be bad style and discouraged.

- no intentional misuse of Wikidata in order to proof a point or to deliberately hurt other sites or projects using our data, even though, narrowly seen, the action is legitimate within Wikidata (this, in particular, is meant to protect the Wikipedias from suddenly displaying misleading data just because their queries might be off or something - go and help fix their queries first, discuss the situation with them, and only then make the changes). We should be aware of the great power we yield on other projects, and should regard this as a token of trust from those projects, and should not deliberately abuse this power.

- no deliberate use of bad sources and then not marking the statement accordingly. Seriously.

There are probably a few ground basic truths that I missed and that we missed so far. I would like if there is some experienced, e.g. collected by the WMF team, about which points should be covered, and then we can start walking around these. This can be ongoing in parallel to the collection of use cases below by Ijon and Spinster for positive and negative behavior.

> - if bots and humans get into a 'fight', humans should have an advantage. Using a bot to inconsiderately overwrite human contributions, particularly repeated human statements, should be bad style and discouraged.

It might be worth expanding this and differentiating between automated human edits and non automated human edits. Or just switching from bots to automation.

Yes, agreed, that's one of the things that would need to be expanded and refined. I was just offering a brain dump :)