This is a guide for npm staff for handling user reports of harassment, package name disputes, and other user-generated pain points.
It is shared publicly in order to add transparency in our process
When in doubt, seek help from your fellow admin staff.
If someone would like to take over a module name from another user, and asks for help with this, please refer them to the "Dispute Resolution" documentation. In cases like this, the two parties tend to be relatively rational and professional, and it is best if we encourage things to continue in that direction.
The policy in brief, where "Alice" is the original author, and "Yusuf" is the person with the dispute:
Yusuf emails Alice, explaining the reasons for wanting the module name, and CC's npm support.
We set a timer for 4 weeks. If that lands on a holiday or something, err on the side of making the delay longer.
At this point, one of three things have happened:
a. Alice and Yusuf have resolved the situation in a way that works for both of them.
b. Alice and Yusuf have reached an impasse, and cannot resolve the dispute.
c. Alice has not responded to Yusuf at all.
By far, (a) is the most common occurrence, and the answer is simple: we do nothing. This is ideal.
When package name disputes can be handled amicably between users without any administrative involvement, everyone feels better about it. Everything we do in these cases should guide towards that endgame when possible.
If Alice has not responded, then we must make a judgment call. There are a few possible considerations:
Abrupt dismissive autocratic administration has a way of upsetting people and bringing them out of hiding. We cannot safely assume that absence is evidence of apathy.
If the module does appear abandoned, or if Yusuf's claim on the module is valid and that the hand-off would be less of a disruption than leaving an abandoned module in npm, then do this:
Reply-all to the thread with something like the following message, customized for your own "voice" as necessary:
Alice, I hope that you are well, and that you only missed this message because your life is too full of wonderful distractions to be bothered dealing with this issue. Yusuf is eager to take over the `fooblx` module on npm, and plans to actively develop it. Currently, it is [not actively developed, marked as deprecated, apparently abandoned, not compatible with the latest Node versions, whatever], so I'd like to hand it off to Yusuf to take over. If this causes you any stress or inconvenience, please let me know as soon as possible.
Set a timer for 1 week.
If Alice responds with concerns, then use diplomacy. Usually this comes down to telling Yusuf, "Sorry, you'll have to choose another name." Mostly, people are pretty receptive to this.
If Alice still does not reply, then reply-all to the thread with something like this:
Alice, As per the email last week regarding the fooblx module, we've decided to hand control over to Yusuf, who will be actively developing it. Yusuf, You are now a package maintainer on the fooblx module. Please leave the existing versions in place, and bump the major version, so that any prior users are minimally impacted. Thank you both for your patience and understanding. --i
Caveats and things to be sensitive of:
Even in those cases, it is often best to try to give users a week or so to do things on their own, so that they can maintain a sense of ownership. Outright and obvious trolling or harassment is never tolerated, however.
These are cases where a user is reporting to us that someone is using the npm system for nefarious ends, or harassing other users in some other way.
In this case, we draw a very hard line, as communicated by our zero-tolerance anti-harassment policy.
Reports of abuse of npm are somewhat different than reports of abuse of npm users.
If a user is publishing a flood of empty squatting packages, spamming, phishing, offensive content, or other childish trolling aimed at the service rather than at a specific user, then the course of action is simple:
If it's possible that they are unaware that their behavior is not allowed, it is a good idea to not ban the user outright, but send them an email asking them to please stop the bad behavior.
Here's an example:
Subject: Empty/duplicate packages removed From: Isaac Schlueter <email@example.com> To: Some User <firstname.lastname@example.org> Cc: npm support <email@example.com> Several empty and duplicated packages belonging to you were removed. Please do not publish empty packages to npm. This causes difficulty for others who may want to use names for new projects. We do not allow "reserving" names for future use. You must have something to publish before taking a package name. Otherwise, we quickly end up with a lot of empty packages, and names being used for no purpose. If you continue to publish empty packages to npm, your username and/or IP address may be blocked from accessing the service. Thank you. --i
Do not mention, involve, or CC the person who reported the bad behavior, as this can only result in added conflict. Briefly thank them for the report, and let them know that it's been dealt with.
This includes both abuse of npm users via the npm service, as well as auxiliary channels such as IRC, Twitter, GitHub, etc.
If it impacts npm users and degrades their experience of using the service, then it's our problem, and we take it seriously.
The vast majority of reports of harassment will come via written media (email, IRC, etc.) If you receive a report of harassment in a non-text format, ask the user for a written account if this is reasonable. If it is not, then take your own notes, or record it in a written format as soon as possible.
A verbal report lasting more than a minute or so is probably better conducted in a quiet/private place rather than in a public space, for the safety and comfort of the reporter. This also decreases the chances for someone to overhear sensitive information that the reporter may not want spread around at an event.
If the user would prefer to remain anonymous, please strip their name from the record prior to sharing it with the rest of the abuse team.
Try to get as much detail as you can about the incident. This will assist us later if we ever need to make a case to defend our choices, as well as inform future decisions about how these incidents could be avoided.
If the following information is not volunteered in the written or verbal report, ask for it/include it, but do not pressure them.
Generally we are not equipped for evidence gathering: do not going around "interviewing" others involved.
If someone reports that a user of the service or an attendee at an event has committed or is threatening violence towards another person, or other safety issues:
If everyone is presently physically safe, involve law enforcement or security only at a victim's request.
In many cases, reporting harassment to law enforcement is very unpleasant and may result in further harassment. Forcing victims to go to law enforcement will reduce reports of harassment (but not actual harassment). For more information, see Why Didn't You Report It?
A staff member can provide the list of emergency contacts and say something like "if you want any help reporting this incident, please let us know" and leave it at that.
These include things like harassing content in package names, conference talks, or harassment that took place in a crowded space.
Simply say "Thanks, this sounds like a breach of our anti-harassment policy. I am going to convene a meeting of a small group of people and figure out what our response will be."
Often, the best approach is similar to handling package name disputes. For example, a user may be a non-native English speaker, and not realize that a given term is offensive. It is our responsibility as the caretakers of npm to attempt to resolve this as amicably as possible.
Other times, this may be a matter of simply deleting some offensive packages and telling the user not to do it again.
In the most egregious cases, it may require banning the user account and/or IP address of an abusive troll.
Offer the reporter/victim a chance to decide if any further action is taken: "OK, this sounds like a breach of our anti-harassment policy. If you're OK with it I am going to convene a meeting of a small group of people and figure out what our response will be."
Pause, and see if they say they do not want this. Otherwise, go ahead.
We should aim to take action as soon as reasonably possible. During the event, a response within the next half-day is usually an appropriate timeframe. After the event you may need more time to gather sufficient decision makers, but ideally responding within the same week or sooner is good.
Available staff should meet as soon as possible after a report to discuss:
Neither the complainant nor the alleged harasser should attend. (If the event was very widely witnessed, such as a harassing talk, this may be an exception to this guideline.) People with a conflict of interest should exclude themselves or if necessary be excluded by others.
As soon as possible, either before or during the above meeting, let the alleged harasser know that there is a complaint about them, let them tell someone their side of the story and that person takes it into the meeting.
As soon as possible after that meeting, let the harasser know what action is being taken. Give them a place to appeal to if there is one, but in the meantime the action stands. "If you'd like to discuss this further, please contact XYZ, but in the meantime, you must <something something>"
Do not ask for an apology to the victim. We have no responsibility to enforce friendship, reconciliation, or anything beyond lack of harassment between any two given users, and in fact doing so can contribute to someone's lack of safety while using our service.
Forcing a victim of harassment to acknowledge an apology from their harasser forces further contact with their harasser. It also creates a social expectation that they will accept the apology, forgive their harasser, and return their social connection to its previous status. A person who has been harassed will often prefer to ignore or avoid their harasser entirely. Bringing them together with a third party mediator and other attempts to "repair" the situation which require further interaction between them should likewise be avoided.
If the harasser offers to apologize to the victim (especially in person), strongly discourage it. In fact, discourage any further interaction with the offended party.
If a staff member relays an apology to the victim, it should be brief and not require a response. ("X apologizes and agrees to have no further contact with you" is brief. "X is very sorry that their attempts to woo you were not received in the manner that was intended and will try to do better next time, they're really really sorry and hope that you can find it in your heart to forgive them" is emphatically not.)
If the harasser attempts to press an apology on someone who would clearly prefer to avoid them, or attempts to recruit others to relay messages on their behalf, this may constitute continued harassment.
All (potentially de-identified) information about harassment reports should be stored for a period of at least 5 years, in an electronic format, accessible only by the npm abuse team.
Lifetime bans are handled by banning a username or IP address. If it ever becomes necessary, we will maintain a lifetime ban of users for in-person events as well.
In general, we handle disputes and harassment quietly. Our code of conduct explicitly forbids harassment, and we maintain our reputability on this point by enforcing that policy appropriately.
However, occasionally these events will spill out into public. In those cases, please let the npm executive team decide how best to communicate with the public.
When necessary, this will be communicated via the npm blog.
When it's necessary to communicate enforcement of our policy at an in-person event, a brief public statement to the attendees such as this would suffice:
"[thing] happened. This was a violation of our policy. We apologize for this. We have taken [action]. This is a good time for all attendees to review our policy at [location]. If anyone would like to discuss this further they can [contact us somehow]."
And then move on with the program.
People may be upset and wish to express their concerns to npm staff. We should be in "making the person feel heard" mode; it's important not to cross into "education mode". Hear them out, take notes as appropriate, thank them for their thoughts.
We should not share additional details of the incident with uninvolved parties.
If a user is upset and a staff member agrees that a wrong was done to them, it helps a lot to just say simply "I'm so sorry." (Rather than "but we tried really hard" or "no one told us" or etc., even if that was true. "I'm so sorry" goes a long way to defusing many people's anger.)
Whether or not a staffer agrees that a wrong was done to them, the user should be armed with an authority they can appeal to if talking wasn't enough. "Please email firstname.lastname@example.org."
After we have had a chance to observe how the anti-harassment and dispute resolution policies work in the real situations, we may wish to change the policy to better address them.
Did anything unforeseen happen that there should be a rule about? Sometimes an unacceptable behavior does not warrant a whole new rule, but should be listed as a specific example of unacceptable behavior under an existing rule.
For the sake of consistency, if there are changes to a rule, we try to apply that rule moving forward, rather than retroactively. If a judgment call is made, record the decision and the justification, and perhaps codify it in a rule going forward so that users can more easily succeed in our community.
This is a living document and may be updated from time to time. Please refer to the git history for this document to view the changes.
Parts of this policy borrow heavily from the Geek Feminism Wikia guide.
This document may be reused under a Creative Commons Attribution-ShareAlike License.
Last modified February 02, 2016 Found a typo? Send a pull request!