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

Open
opened 1 month ago by fnetX · 8 comments
fnetX commented 1 month ago
Collaborator

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.
hw commented 1 month ago
Owner

I like the tools idea

I like the tools idea
fnetX commented 3 weeks ago
Poster
Collaborator

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 😜
hw commented 3 weeks ago
Owner

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!
hw commented 3 weeks ago
Owner

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?
fnetX commented 3 weeks ago
Poster
Collaborator

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.
fnetX commented 2 weeks ago
Poster
Collaborator

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.
hw commented 2 weeks ago
Owner

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
fnetX commented 1 week ago
Poster
Collaborator
  • eventually give feedback to git fsck results
+ eventually give feedback to git fsck results
Sign in to join this conversation.
Loading…
There is no content yet.