Codeberg/Community
54
325
Fork
You've already forked Community
12

User hints: add a license, resource usage etc #414

Open
opened 2021年03月09日 23:26:11 +01:00 by fnetX · 11 comments
Owner
Copy link

In #409 we discussed a way to hint users through Codeberg, with links to the Docs here and there and also nicely asking to follow the ToS here and there, especially when creating repos (and telling they should not eat up all disk space, contain a license file etc).

Transfer:

It might be an interesting idea to work out a 👉 hint system for users to tell them things where they need it. Take a private repo for example, we could say "Hey, please be aware that private repos are meant to prepare releases to the public only" or something like this. This could be extended from "Hey, don't forget to add a licence" on the first repo (or repos without detected licence) to some welcoming messages for new users about checking out the docs etc.

I think, this could become quite annoying if exagerated, so we could break down this idea into some scriptable or at least definable announcement system.

  • show a "Welcome 💙" messages for new users and link to some getting started guide
  • users who are active for a year could be asked whether they already considered joining Codeberg
  • people could be tagged for extreme resource usage - and told "Hey, don't eat up all our disk space in personal projects" or "Want to store more Gigs than everyone else? Consider a donation to make this possible 💸"
  • users which haven't been logged in for a while could be welcomed back
  • on extreme productivity spikes, we could show a user some "Big thank you 🤗" or some "Hold on, you're on a commit streak 🚝" if they are contributing steadily
  • etc ...

One idea was to create hints on the repos.
@hw:

I would like a banner helping people when they need help: tell them if license files are missing, tell them about problematic (non-free/non-derivative/non-enforcable/...) licence choices, and potentially unintended resource abuse (big hidden repos, repos containing only large binary blobs, etc).

Another idea could be to create a Codeberg bot with a fancy name refering to mining or something like that, that opens issues in repos alike "Welcome, don't forget to add a licence" or "Oh, you eat up a lot of disk ..." and stuff like that. It could add much more explanation than a simple help message, it can be implemented using external tools and it could be made in a funny way.

In #409 we discussed a way to hint users through Codeberg, with links to the Docs here and there and also nicely asking to follow the ToS here and there, especially when creating repos (and telling they should not eat up all disk space, contain a license file etc). Transfer: > It might be an interesting idea to work out a 👉 hint system for users to tell them things where they need it. Take a private repo for example, we could say "Hey, please be aware that private repos are meant to prepare releases to the public only" or something like this. This could be extended from "Hey, don't forget to add a licence" on the first repo (or repos without detected licence) to some welcoming messages for new users about checking out the docs etc. > > I think, this could become quite annoying if exagerated, so we could break down this idea into some scriptable or at least definable announcement system. ⏬ > - show a "Welcome 💙" messages for new users and link to some getting started guide > - users who are active for a year could be asked whether they already considered joining Codeberg > - people could be tagged for extreme resource usage - and told "Hey, don't eat up all our disk space in personal projects" or "Want to store more Gigs than everyone else? Consider a donation to make this possible 💸" > - users which haven't been logged in for a while could be welcomed back > - on extreme productivity spikes, we could show a user some "Big thank you 🤗" or some "Hold on, you're on a commit streak 🚝" if they are contributing steadily > - etc ... One idea was to create hints on the repos. @hw: > I would like a banner helping people when they need help: tell them if license files are missing, tell them about problematic (non-free/non-derivative/non-enforcable/...) licence choices, and potentially unintended resource abuse (big hidden repos, repos containing only large binary blobs, etc). Another idea could be to create a Codeberg bot with a fancy name refering to mining or something like that, that opens issues in repos alike "Welcome, don't forget to add a licence" or "Oh, you eat up a lot of disk ..." and stuff like that. It could add much more explanation than a simple help message, it can be implemented using external tools and it could be made in a funny way.
Member
Copy link

I like the tools idea

I like the tools idea
Author
Owner
Copy link

Open questions:

  • How about repositories with no or external issue tracker?
    Report the findings to an admin for manual review then?
  • Should the bot search the issues if they already exist or keep a local cache for that case? Searching is more failure-tolerant I think ... it could comment every time it passes by and asks nicely if there was update (when it detects none)

My concept is currently the following:

  • create a bot that rotates through all the users and organizations
  • for every user: go through the repositories until you find one that does need a notice
  • report either all the problems in one issue or create separate ones
  • continue with the next user to avoid someone receiving a lot of issues at once ... they might also be nice enough to fix their other repositories themselves

Although the bot could in theory open issues in private repositories, I'd rather add an annoying notice there. There are some currently 'accepted' use cases for private repos and I think there is close to no value added in this case.
So I'd prefer to add a banner in the template that shows on private repos and explains what they are for. I think, people could accept such a banner for their legitimate use cases 😜

Open questions: - How about repositories with no or external issue tracker? Report the findings to an admin for manual review then? - Should the bot *search* the issues if they already exist or keep a local cache for that case? Searching is more failure-tolerant I think ... it could comment every time it passes by and asks nicely if there was update (when it detects none) My concept is currently the following: - create a bot that rotates through all the users and organizations - for every user: go through the repositories until you find one that does need a notice - report either all the problems in one issue or create separate ones - continue with the next user to avoid someone receiving a lot of issues at once ... they might also be nice enough to fix their other repositories themselves Although the bot could in theory open issues in private repositories, I'd rather add an annoying notice there. There are some currently 'accepted' use cases for private repos and I think there is close to no value added in this case. So I'd prefer to add a banner in the template that shows on private repos and explains what they are for. I think, people could accept such a banner for their legitimate use cases 😜
Member
Copy link

I like this a lot.

continue with the next user to avoid someone receiving a lot of issues at once ... they might also be nice enough to fix their other repositories themselves

nice!

I like this a lot. > continue with the next user to avoid someone receiving a lot of issues at once ... they might also be nice enough to fix their other repositories themselves nice!
Member
Copy link

How about repositories with no or external issue tracker?

Not sure how many these currently are. @ashimokawa : do you know?

Should the bot search the issues if they already exist or keep a local cache for that case? Searching is more failure-tolerant I think ... it could comment every time it passes by and asks nicely if there was update (when it detects none)

It should be quite cheap to do something like curl/wget/requests.get("https://codeberg.org/Codeberg/Community/raw/branch/master/$file) for file in ["LICENSE", "LICENSE.md", "LICENSE.rst"] etc, and check if any of these succeed. We could trigger this from a global commit webhook, and run asynchronuously once for all repos older than the launch date.

Searching an issue via API is documented in https://codeberg.org/api/swagger#/issue, as this only happens if there is no license file in place, it should not be too expensive?

> How about repositories with no or external issue tracker? Not sure how many these currently are. @ashimokawa : do you know? > Should the bot search the issues if they already exist or keep a local cache for that case? Searching is more failure-tolerant I think ... it could comment every time it passes by and asks nicely if there was update (when it detects none) It should be quite cheap to do something like `curl/wget/requests.get("https://codeberg.org/Codeberg/Community/raw/branch/master/$file) for file in ["LICENSE", "LICENSE.md", "LICENSE.rst"]` etc, and check if any of these succeed. We could trigger this from a global commit webhook, and run asynchronuously once for all repos older than the launch date. Searching an issue via API is documented in https://codeberg.org/api/swagger#/issue, as this only happens if there is no license file in place, it should not be too expensive?
Author
Owner
Copy link

Searching an issue via API is documented in https://codeberg.org/api/swagger#/issue, as this only happens if there is no license file in place, it should not be too expensive?

Yeah, that makes sense. I first thought about a local cache for speed, but this would require that someone keeps it up2date or the bot will open issues again.
So probably better to rely on the issue tracker as data storage and be independent of the bot operator.

> Searching an issue via API is documented in https://codeberg.org/api/swagger#/issue, as this only happens if there is no license file in place, it should not be too expensive? Yeah, that makes sense. I first thought about a local cache for speed, but this would require that someone keeps it up2date or the bot will open issues again. So probably better to rely on the issue tracker as data storage and be independent of the bot operator.
Author
Owner
Copy link

How about repositories with no or external issue tracker?

A super-hacky workaround that just came to my mind (and I somehow start to like it):
Push a new branch with a descriptive name that just contains a README that explains the matter (no TOS compliance etc) and setting this as the default branch. All repository content is available unmodified, the README could include a note that users can change the branch.

> How about repositories with no or external issue tracker? A super-hacky workaround that just came to my mind (and I somehow start to like it): Push a new branch with a descriptive name that just contains a README that explains the matter (no TOS compliance etc) and setting this as the default branch. All repository content is available unmodified, the README could include a note that users can change the branch.
Member
Copy link

not sure if this is worth the hassle unless we know that these are a significant number

not sure if this is worth the hassle unless we know that these are a significant number
Author
Owner
Copy link
  • eventually give feedback to git fsck results
+ eventually give feedback to git fsck results
Author
Owner
Copy link

A first step is the added banner to huge private repos (added 2 days ago with Gitea 1.15 deployment)

A first step is the added banner to huge private repos (added 2 days ago with Gitea 1.15 deployment)

update?

update?

@fnetX Isn't a license mandatory by the Terms of Use?

(2) Our service is open for all projects covered by a free software or open source licence, as defined by either the Free Software Foundation (FSF) or the Open Source Initiative (OSI).

Still, it is a good idea to remind users of adding a proper free software license.

@fnetX Isn't a license mandatory by the Terms of Use? > (2) Our service is open for all projects covered by a free software or open source licence, as defined by either the Free Software Foundation (FSF) or the Open Source Initiative (OSI). Still, it is a good idea to remind users of adding a proper free software license.
Sign in to join this conversation.
No Branch/Tag specified
main
No results found.
Labels
Clear labels
accessibility

Reduces accessibility and is thus a "bug" for certain user groups on Codeberg.
bug

Something is not working the way it should. Does not concern outages.
bug
infrastructure

Errors evidently caused by infrastructure malfunctions or outages
Codeberg

This issue involves Codeberg's downstream modifications and settings and/or Codeberg's structures.
contributions welcome

Please join the discussion and consider contributing a PR!
docs

No bug, but an improvement to the docs or UI description will help
duplicate

This issue or pull request already exists
enhancement

New feature
infrastructure

Involves changes to the server setups, use `bug/infrastructure` for infrastructure-related user errors.
legal

An issue directly involving legal compliance
licence / ToS

involving questions about the ToS, especially licencing compliance
please chill
we are volunteers

Please consider editing your posts and remember that there is a human on the other side. We get that you are frustrated, but it's harder for us to help you this way.
public relations

Things related to Codeberg's external communication
question

More information is needed
question
user support

This issue contains a clearly stated problem. However, it is not clear whether we have to fix anything on Codeberg's end, but we're helping them fix it and/or find the cause.
s/Forgejo

Related to Forgejo. Please also check Forgejo's issue tracker.
s/Forgejo/migration

Migration related issues in Forgejo
s/Pages

Issues related to the Codeberg Pages feature
s/Weblate

Issue is related to the Weblate instance at https://translate.codeberg.org
s/Woodpecker

Woodpecker CI related issue
security

involves improvements to the sites security
service

Add a new service to the Codeberg ecosystem (instead of implementing into Gitea)
upstream

An open issue or pull request to an upstream repository to fix this issue (partially or completely) exists (i.e. Gitea, Forgejo, etc.)
wontfix

Codeberg's current set of contributors are not planning to spend time on delegating this issue.
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
4 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Codeberg/Community#414
Reference in a new issue
Codeberg/Community
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?