Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Moderation concept for issues on git repositories #12

Open
joubertredrat opened this issue Nov 2, 2016 · 6 comments
Open

Moderation concept for issues on git repositories #12

joubertredrat opened this issue Nov 2, 2016 · 6 comments
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@joubertredrat
Copy link
Contributor

joubertredrat commented Nov 2, 2016

Hi guys,

Open source projects is amazing, but sometimes, noob users usually more disturb than help and collaborate on issues.
Because this I think that is good idea to implement moderation option on issues, so repo owerns and moderators
may ban user on specific issue or on all repo issues.

Example, I want to ban octocat on my awesome-devops repo on "Add Puffin" because she is spamming on issue,
I can enable ban and put reason "you're not following the rules", then when octocat try to comment,
will not possible, because is banned and will display to octocat "You can't post on this issue, reason: you're not following the rules".

Like this, if octocat is banned on all repo, she can't open new issue and display too "You can't open this issue, reason: I don't like you".

This idea is to prevent this as example: git/git#233

This is only a concept, what you think guys?

Original idea: https://gist.github.com/joubertredrat/05759a27b71a4e2da72f9079edc9694b
Issue on GitLab: https://gitlab.com/gitlab-org/gitlab-ce/issues/19801

Reference: gogs/gogs#3658

@jhasse
Copy link

jhasse commented Nov 3, 2016

"You can't open this issue, reason: I don't like you"

Hm ... thats exactly the reason why I dont like this idea. It should be obvios to outsiders that a certain person is blocked. Maybe still show the post with a "Marked as spam" spoiler?

@tboerger tboerger changed the title [Feature suggestion] Moderation concept for issues on git repositories Moderation concept for issues on git repositories Nov 3, 2016
@tboerger tboerger added the type/enhancement An improvement of existing functionality label Nov 3, 2016
@tboerger tboerger added this to the 1.x.x milestone Nov 3, 2016
@joubertredrat
Copy link
Contributor Author

joubertredrat commented Nov 3, 2016

@jhasse a little question, is you as owner of your project can control your code by PRs, why not you can control your issues from spammers as example?

I will explain with example. I hate @bkcsoft and he is owner of this repo, I want to irritate him, then, I will open a lot of Issues spamming and PR's bombs with robots. Today in Github, @bkcsoft can't do anything but close the issues and refuse PR, maybe report to GitHub e maybe Github will ban me.

This is strange because @bkcsoft is owner but don't have control of your repository issues. The idea of moderation and just for that, @bkcsoft already have control of your code on repository and with this concept, have control of issues too.

Gitlab is studing this case, https://gitlab.com/gitlab-org/gitlab-ce/issues/19313

PS: @bkcsoft I hate you only on example 👍

@xinity
Copy link
Contributor

xinity commented Nov 3, 2016

i like to idea to be able to cleanup irrelevant issues (or so to speak), but i'm sure it will take a huge amount of energy to build, implement and manage.

i'd be happy to know how many projects implement this moderation system ?
don't get me wrong, it's just i'm wondering if it's really worth it, considering the overhead it will have on the moderation team

@strk
Copy link
Member

strk commented Nov 3, 2016

I think the these kind of attacks should be prevented somewhat automatically (rate limiting, spam filtering)

@lunny
Copy link
Member

lunny commented Nov 3, 2016

Good idea. But I think this will not be the emphasis currently.

@tboerger tboerger added type/proposal The new feature has not been accepted yet but needs to be discussed first. and removed type/enhancement An improvement of existing functionality labels Nov 3, 2016
lunny referenced this issue in lunny/gitea Feb 7, 2019
* Adds functions to handle checking out branches and moving files

Adds support for checking out a new branch
Fix for branch pull requests

* Adds methods to get files changes between two commits
lunny referenced this issue in lunny/gitea Feb 7, 2019
Rename file from utlis.go to utils.go
@worthy7
Copy link

worthy7 commented Oct 7, 2019

Just to add my 2 cents here, I think if this is a not a feature in GitHub, then we shouldn't really try to copy it.
No doubt this idea has been raised with GitHub internally and they decided not to implement it (to my knowledge at least?). So although it sounds good, this is just one of the down-sides of open source really. on the upside - unlimited contributors!

CL-Jeremy pushed a commit to CL-Jeremy/gitea that referenced this issue Mar 21, 2021
Ship esbuild binaries for all platforms in tarball
@lunny lunny removed this from the 1.x.x milestone Mar 20, 2023
zengchen1024 added a commit to zengchen1024/gitea that referenced this issue Dec 27, 2023
* refactor list files

* check if the file is lfs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Development

No branches or pull requests

7 participants