From c04dcc2e7d834218ef2d4194331e383402495ae1 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Wed, 10 Apr 2024 20:07:22 +0200 Subject: Adding upstream version 2:20.4+dfsg. Signed-off-by: Daniel Baumann --- docs/codeofconduct/CodeOfConduct.md | 196 ++++++++++++++++++++++++++++++ docs/codeofconduct/ForumUserBanning.md | 15 +++ docs/codeofconduct/ModerationRules.md | 30 +++++ docs/codeofconduct/ModeratorGuidelines.md | 54 ++++++++ 4 files changed, 295 insertions(+) create mode 100644 docs/codeofconduct/CodeOfConduct.md create mode 100644 docs/codeofconduct/ForumUserBanning.md create mode 100644 docs/codeofconduct/ModerationRules.md create mode 100644 docs/codeofconduct/ModeratorGuidelines.md (limited to 'docs/codeofconduct') diff --git a/docs/codeofconduct/CodeOfConduct.md b/docs/codeofconduct/CodeOfConduct.md new file mode 100644 index 0000000..856ed56 --- /dev/null +++ b/docs/codeofconduct/CodeOfConduct.md @@ -0,0 +1,196 @@ +# **Code of Kodi** + +## **Introduction:** + +- This document should hopefully be entirely common sense and how most + people would normally act anyway. +- In an ideal world it would be entirely unnecessary, but with the impersonal + nature of internet communications and with differing viewpoints on certain + sensitive topics, some guidelines have proven to be necessary at times. + +## **Our Aims:** + +- Our primary aim is to make Kodi the best open source media player + product that it can be. + +- To achieve this, we aim to create a supportive, welcoming and + open team environment where anyone can participate and submit code or + time/knowledge to help improve things. + +- Our team environment should be welcoming and safe, free of + harassment, discrimination and undesirable behaviour to individual + or groups of members. + +- Whilst we do not expect everyone to get along and agree all of the + time, we do expect people to be civil and professional to one + another. + +## **Our Expectations:** + +1. Contributions from anyone are welcome, and should be encouraged. + Where criticism or correction is needed, try to make it respectful, + constructive, supportive and positive. + +1. Contributors should act in the best interest of the community and of + the Kodi project. + +1. We're all volunteers -- people will give whatever time and effort + they wish to. No-one should be made to do anything they don't want + to. + +1. Discrimination, harassment, threatening/bullying behaviour, trolling + or insulting/derogatory language will not be tolerated in any form + via any Kodi channel or site. + +1. Respect the contribution and efforts of others -- treat them as + you'd like them to treat you. + +1. Publication and sharing of confidential information, both relating + to Kodi and to individual's personal data, is only by explicit permission + of the relevant information owner and person(s) concerned, as applicable. + +1. Work on Kodi is a team effort. + Individual contributions are highly appreciated and to be respected, + but they do not empower those contributors to make decisions + affecting the overall management of the project. + +1. If you are a team member, you may have the title of "Team Kodi Member" + (or variants thereof) in environments like the Kodi forum. You are of + course free to state your own opinions on topics, but for more + controversial ones, please ensure to explicitly state that what you + post is your own opinion and not that of the team or the project. + +1. Discussions, debate and disagreement are a natural part of a working + team. Account should be taken though for the impersonal nature of + internet discussions, and for things like language and cultural + norms. Don't be too quick to assume ill intent or to take offense, + and respect people's boundaries and feelings. + +1. Where you can, be helpful to fellow contributors and share your + knowledge and skills. We all have to start somewhere, and they may + be able to return the favour later or contribute more fully as a + result. + +1. No-one is perfect -- tolerate honest mistakes that may be made, + learn from them and help to repair them when you can. And if they're + yours, be honest about them and apologise. + +1. Submitted code and other important documentation will be peer + reviewed. Comments, suggestions and constructive criticism should be + taken with good grace and not as a slight or insult to the work and + effort put in. + +1. There is an over-riding principle that accepted work, postings or commits + should not be reverted, edited or otherwise rejected without discussion + with the original author. + + Recognising that changes do sometimes need to be made (for example, code + commits which break master compilation or simple typos that shouldn't be + left and forgotten), a reasonable attempt - reflecting the spirit of the + change/reversion - should be made to liaise with the original author prior + to making any modifications. If this isn't practical, it is considered good + practice to appropriately peer review any potential changes prior to + application to minimise risks of further breakage. + +1. In case of dispute the working group or the board should be asked + to mediate. + +## **Scope:** + +- This code covers all services supplied by and used by Team Kodi, + such as: + + - The official GitHub repos. + + - The Kodi forum. + + - The Kodi wiki. + + - The Kodi Slack and IRC channels. + + - Official Kodi social media channels. + + - Devcon. + +- Anyone who contributes to the Kodi project on any of these channels + is expected to abide by this code. + +## **Enforcement:** + +- Violations of this code which cannot be dealt with by simple + discussion should be reported to the working group via conduct@kodi.tv . + The group will then review the issue and mediate between the parties involved. + +- The identity of the reporter and where appropriate the nature of the issue + should remain confidential and be handled with care and sensitivity. + +- The procedure upon receiving a report should be: + + 1. The group should review the report, and any member directly + involved or having a vested interest in the outcome should + recuse themselves. + + 1. Any public disputes or discussions should be brought to a close + with a clear statement that the issue is under review, and that + any further 3rd party comment should be directed to the group + via the group email address. + + 1. All individuals concerned with the issue will be contacted + privately and an attempt made to clarify their individual + viewpoints and concerns. Particular emphasis on identifying and + resolving any misunderstandings, mistranslations or + misinterpretations will be made. + + 1. In case of such identifications, the group will attempt to + mediate between the parties involved to resolve the problem if + possible. + + 1. The behaviour of all parties involved will be reviewed, and in + cases where the code has been broken (e.g. harassment, + discrimination or aggression) further action will be discussed + against the individual(s) concerned. + + 1. This action will depend on the severity of the transgression and + on the history of the individual. Some guidelines for + appropriate measures for team members are: + + - First offence -- a warning. + + - Second offence -- loss of privileges for a week. + + - Third offence -- loss of privileges for a month. + + - Fourth offence -- permanent revoking of privileges. + + - Final offence -- banning from all Kodi services. + + - Privileges will depend on the nature of the issue, but may + include team membership, GitHub repo push access, forum + moderator powers, wiki account access and social media + account access. + + For individuals that are not members of Team Kodi, there are no + privileges that could be revoked. Appropriate measures therefore + include warnings and revoking access to services such as the + forum or the `xbmc` organization on GitHub temporarily or + permanently. + +## **Stakeholders:** + +- *Kodi Foundation Board* -- the elected five directors and management + of the XBMC Foundation. + +- *Working Group* -- the team assigned by the board to create this + document and to oversee its administration. + +- *Contributors* -- volunteers who give input into the upkeep and + improvement of Kodi and its community, be they Team Members or + interested third parties. This includes both code and posts made to + the forum, the wiki or on official social media channels. + +## **Related Documents:** + +- [Forum rules](https://kodi.wiki/view/Official:Forum_rules) +- [Moderation rules (the basics)](https://github.com/xbmc/xbmc/blob/master/docs/codeofconduct/ModerationRules.md) +- [Moderator guidelines](https://github.com/xbmc/xbmc/blob/master/docs/codeofconduct/ModeratorGuidelines.md) +- [Forum banning code of conduct](https://github.com/xbmc/xbmc/blob/master/docs/codeofconduct/ForumUserBanning.md) \ No newline at end of file diff --git a/docs/codeofconduct/ForumUserBanning.md b/docs/codeofconduct/ForumUserBanning.md new file mode 100644 index 0000000..8921bee --- /dev/null +++ b/docs/codeofconduct/ForumUserBanning.md @@ -0,0 +1,15 @@ +Originally posted by DarrenHill on the forum + +From discussions earlier on the slack team channel and following on from recent events, I was asked to propose a code of conduct for bans and user banning on the forum, to be followed by all with moderator powers. + +1. When required and when the case is clear, spambots and spam accounts should be dealt with using the "Goodbye Spammer" moderator tool. However if the user/post is not 100% certainly spam, then a second opinion must be sought on the slack #moderator channel as once GBS is used, it cannot be undone. + +2. For users repeatedly asking for support for banned add-ons or those ignoring warnings or legitimate moderator requests then the normal "three strikes" rule should be applied, with an official warning after the second strike and a short ban (up to one week) applied after the third strike. + +3. Where users are being abusive, aggressive or otherwise in violation of the forum rules, warnings should be given when possible, but if a ban is necessary then a second opinion must be obtained, unless the ban is very temporary, 3 days or less, with the explicitly stated reason of cooling heads. This second opinion may be obtained either on the slack channel or by using the forum report post feature with the request that another moderator review the situation and take action if they agree it necessary. Lengthy bans (anything over 3 months) should be done as a team decision. Each ban from this section, whether long or short, shall include a note explaining the reason for the ban so that there is no confusion later. + +4. If you are personally involved with the issue under discussion, or if there are any other conflicts of interest which may prejudice fair and judicial usage of moderator powers, then you have to avoid any direct involvement beyond highlighting the problem to the moderator team. + +5. Normally if a ban is to be lifted or modified it should be done by the original moderator who imposed the ban. But if the situation requires it, the ban may be reviewed by the moderator team as a whole, and if the majority decides that a change or revoke is required then the change may be made (and no further changes made without a second discussion). + +This code applies to all users with moderator powers on the board, and must be followed by them. At the moderator team's discretion, failure to do so may result in suspension or removal of such powers for a period of initially a week, with longer periods considered for more serious issues. \ No newline at end of file diff --git a/docs/codeofconduct/ModerationRules.md b/docs/codeofconduct/ModerationRules.md new file mode 100644 index 0000000..2ad7b77 --- /dev/null +++ b/docs/codeofconduct/ModerationRules.md @@ -0,0 +1,30 @@ +Moderation Rules - Originally posted by Kib on the forum. + +With great power comes great responsibility, and it is important to not misuse the power we have received. +Below are a set of basic rules for the forum moderation that we have come up with. +In case a rule is missing that you think should be added, feel free to discuss. + +**Writing posts or replies** +- Be civil, no matter how infuriating other persons are. +- Unsure what to do? Ask a fellow moderator or the team in this forum! + +**Editing posts** +- Never edit posts without explaining that you did so in your edit. +- Editing to remove harmful content is OK. +- Editing broken links or confusing misspelling to fix them is OK +- Editing posts because you do not agree with what was said, is NOT ok. + +**Deleting posts or whole threads** +- Don't. It's much more preferred to move them to the garbage or edit the offending bits out (See above) +- For spam: use the stopforumspam link in the top right of the post, or ask an admin when that is not possible. + +**Moving threads** +- When moving threads, when possible leave a non-permanent redirect for a number of days. 7 is a good number, but 3 works as well. Use your own intuition. Wink +- Reply to the thread stating that you moved it, ergo "Moved to support section because this does not belong in Android development" + +**Sticking / Unsticking threads** +- When in doubt, don't stick or unstick +- Only sticky threads that will be valid for a long time. +- Do not sticky many threads, it gets in the way of browsing the forum +- If many threads are stickied, it is usually better to consolidate the information by making a reference sticky that points to all the threads +- Contact the author before unstickying threads \ No newline at end of file diff --git a/docs/codeofconduct/ModeratorGuidelines.md b/docs/codeofconduct/ModeratorGuidelines.md new file mode 100644 index 0000000..7a6ef04 --- /dev/null +++ b/docs/codeofconduct/ModeratorGuidelines.md @@ -0,0 +1,54 @@ +Moderator Guidelines - originally posted on the forum by DarrenHill + +As suggested by keith on the slack channel, I thought it might be useful to have a few notes and suggestions for how to moderate around here, especially as we have several new members of the team recently. So below are my thoughts on it - please feel free to add to the thread any additional ones that you may have (or that you may disagree with in mine). + +**General stuff:** +- Above all else, try to stay calm and not get emotionally involved. Moderating whilst angry, upset or similar (or drunk etc) can often lead to making situations worse rather than better. +- If you're ever in doubt, take a few moments to check stuff out, or ask for support on the slack channel or this section. We're a moderator team, not a bunch of individuals. +- Don't be too quick to attribute stuff to malice or deviousness that can be accounted for by simple stupidity or ignorance. +- If you do something to a thread or post, make it clear what you have done by adding a note or a new post to it. This includes moving threads and splitting/merging them or chopping posts out for binning. +- All actions performed are recorded in the moderator logs. +- Support one another, and those users who are kind enough to flag up posts and thread (either by the report system or via posts in threads) that may need action. +- Super Moderators (and many Team Kodi members) have mod powers everywhere, whilst normal Moderators have the same powers but in more restricted areas of the forum. + +- We do not support any installation containing banned add-ons, with the exception of assisting users in removal of them. If the thread is asking about them directly, then bin it. But if it's more tangential (e.g. evidence in a debug log) then inform the user of their presence and that this precludes any support, but leave the thread open to allow them to react and hopefully be educated about it (binning via the delayed moderation tools can be useful here as well). You can also redirect them to JJD-UK's new sticky threads about such add-ons. +- If you do something right, most people won't notice. But if you do something wrong, don't be surprised if certain of our membership take it upon themselves to give you grief. Don't take it personally, it's a thankless task sometimes (and flameproof Kodi-branded underwear is optional). +- Make use of the wiki, and pages like the forum rules, the banned add-ons list, the Official:Trademark Policy and the notes for the first time user. Also Nate's blog post and Martijn's blog post are both useful educational readings for our more naïve users. +- If an action has been performed by another moderator or team member that you do not agree with, please consult with them on slack or here about it for clarification and discussion. Do not arbitrarily undo actions by other mods without doing so. Whilst everyone makes mistakes sometimes, there may be more to it than initially appears. + +**Moderator tools** +- All of the mod tools except goodbye spammer are accessible via the drop-down menu at the bottom-right of your web browser (can't comment about tapatalk as I don't use it, but I think it's more limited). +- If you're on Tapatalk and need something done that you can't do directly, just use the report function, make a thread/post here or ask on slack. +- If you're not sure what a tool does or how it works, ask either on slack or here. And if necessary, make a new thread or two in the garbage section and practice with them on how to split/merge threads etc and how to bin stuff. +- With the exception of "goodbye spammer" and thread/post deletion actions, there's no moderator tool action that cannot be undone again. +- Except for spam posts, always use the garbage section (via the tools to "move to garbage" or "move to spam & rule violation") rather than permanently deleting. +- The "move to garbage" and "move to spam & rule violation" are your most commonly used tools. Both move the thread to the bin and automatically close (lock) it. The only differences are the automatic post that is added to the thread, and that "move to garbage" leaves a redirect whereas "spam & violation" doesn't. +- If you do bin a thread, try to add a post to it first explaining why you're doing so. + +- Obvious spam post accounts should be dealt with via the "goodbye spammer" tool (the yellow warning triangle on the right hand side of the post). Note that this (after a confirmation screen) deletes the account, IP blocks its source and removes permanently all posts/threads made by that account. It is permanent and cannot be (easily) undone. +- Goodbye spammer can only be used on users with less than 30 posts. If a spambot has been particularly verbose and exceeded that, you may need to delete a number of their threads manually to bring the count below this so that it can be used. Note this is one of the few cases where thread permanent deletion should be used, as just binning the threads won't bring the count down to re-enable goodbye spammer. +- If you're not sure if a post/account is spam or not, consult with the team and also try a Google (or other engine) search. Spambot posts get spider-scraped and will show up in searches, making multi-site spambots obvious. +- Delayed moderation actions (the first option in the drop-down menu) can be useful for times when you may want to perform an action later (e.g. close a thread temporarily now and then use a delayed moderation action to reopen it at a later time without having to remember then to go and do so. + +**Housekeeping** +- Moving threads between sections is one of the most common jobs. Not glamorous, but it is needed. +- If you move a thread (via the move/copy thread tool), generally it's best to leave a redirect (the default option when you select the tool) so the users can still find it. Personally I use 7 days duration for all except the discussions section where I use 3, but it's a matter of personal taste. If you don't set anything, the redirect shortcut will stay forever. +- Also if you move a thread, leave a note in it to say that you've done so. +- Discussions isn't for support requests - that's what the main support sections are for. +- Threads moved to off-topic can still be posted to by anyone, but normal users cannot start threads in that section. +- If you bin a thread that contains dodgy links, please remember to edit it and remove them. The bin is publicly visible, so can be harvested for such things by enterprising idiots. + +**Warnings and banning** +- Banning someone is an extreme measure, and should only be done "off the cuff" for short-term duration (certainly no more than a 2 week ban, ideally less) as a direct result of threatening or insulting behaviour (for the latter, something that goes materially beyond a simple breach of 2.1 of the Forum Rules). +- Any longer ban should only be made after discussion (on Slack) with at least one other moderator. +- Consider also the seniority/contribution of the person in question, and thus the proportionality of the penalty. +- While this is not a democracy, we do value our users and owe them some degree of transparency as to our actions. As such, warnings should be used where possible before bans are actioned (although of course that is not always feasible if a user needs removing quickly). +- Where possible, warnings should be used before bans are actioned (the "3 strikes" rule, although of course that is not always feasible if a user needs removing quickly). +- Both can be done either via the buttons below posts or via the profile page of the user. +- Warnings can be set to anything from 10% to 100% (click the "custom reason" button in the warning page to access that, the "points" setting is per 10% so 4 points is 40%). In that page you also put information that will be seen by the user as to what the reason for the warning is, and how long it will last. +- Note that all a warning does practically is increase the figure visible below the user avatar beside posts. A 100% warning does not trigger any other action automatically, it's basically cosmetic. +- Bannings work in a similar fashion, but of course actually deny the user account access to being able to log into the forum. They can be set for anything from 1 hour to a permanent ban. +- Note that banning does not block IP addresses (although admins here can do that if necessary), but the creation of a second account to get around a ban is itself a forum rules violation and can be cause for such an IP block. +- It is possible to reverse both warnings and bans, but do not do so without consulting and discussing with the moderator or team member who initially applied them. + +I would hope most of the above is obvious, plus I'm sure there are bits that should be there but I've forgotten. But please feel free to add to the suggestions and guidelines so we can do things consistently and well across the whole team and forum. \ No newline at end of file -- cgit v1.2.3