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

Tour for new users #1329

Open
opened 2023年11月02日 11:35:08 +01:00 by fnetX · 2 comments
Owner
Copy link

Comment

I discussed this idea in the past (IIRC it was around the hackathon one year ago) and got some positive feedback. The situation has changed, and I want to propose this with new arguments supporting the idea.

The initial idea was to create an optional tour for new users, onboarding them to Codeberg. The tour could explain the tools that everyone wants to use (issue tracking, repo creation, migrations etc), as well as potentially hidden features ("Did you know that ...?").

Due to increasing spam signups and the idea to design a new signup process (#1297), the idea could be extended to turn this from an optional after-registration to a mandatory external sign-up tool.

Here is how it could look like:

  • registration page links to external widget
  • user enters username
    • checked if available / valid
    • used for personalization during the signup process
  • user is asked for intended use case (development, issue triaging, design etc) and potentially about their skills ("do you know Git?", "Have you already contributed to software development?")
    • allows for customizations during the introduction
    • e.g. we don't need to introduce Git to someone who just wants to report an issue
  • we present the user with the goals of Codeberg
    • promote Free/Libre Software and explicitly spell out our requirements, maybe also mention our rules regarding private repositories
    • explain that we're a non-profit and rely on donations
  • optional section about tips and tricks (can be skipped)
  • after the tutorial, a new account is created via the API and usable to the user

The design goals of the tool will be:

  • help users to get started
  • have an accessible sign up flow
    • i. e. no visual captcha
  • require a certain amount of time (i.e.. no fast clicking through pages) to make mass-account-creation e.g. for spamming unattractive (maybe 3.5 to 5 minutes?)
  • customize the tour to keep it relevant for users, allow them to skip some potentially boring / irrelevant sections

It will require some work, but I am sure that it solves a lot of problems and is a good investment.

Open questions of mine:

  • where will we verify the email? Maybe send the email during the process to reduce waiting time, but not immediately at the beginning to prevent mass-mailing foreign mail addresses?
  • is explicit waiting time acceptable? I think it is - even if an existing user needs a second account (e..g. for a bot), investing five minutes once is probably okay, while it is hopefully not for spammers
### Comment I discussed this idea in the past (IIRC it was around the hackathon one year ago) and got some positive feedback. The situation has changed, and I want to propose this with new arguments supporting the idea. The initial idea was to create an optional tour for new users, onboarding them to Codeberg. The tour could explain the tools that everyone wants to use (issue tracking, repo creation, migrations etc), as well as potentially hidden features ("Did you know that ...?"). Due to increasing spam signups and the idea to design a new signup process (#1297), the idea could be extended to turn this from an optional after-registration to a mandatory external sign-up tool. Here is how it could look like: - registration page links to external widget - user enters username - checked if available / valid - used for personalization during the signup process - user is asked for intended use case (development, issue triaging, design etc) and potentially about their skills ("do you know Git?", "Have you already contributed to software development?") - allows for customizations during the introduction - e.g. we don't need to introduce Git to someone who just wants to report an issue - we present the user with the goals of Codeberg - promote Free/Libre Software and explicitly spell out our requirements, maybe also mention our rules regarding private repositories - explain that we're a non-profit and rely on donations - optional section about tips and tricks (can be skipped) - after the tutorial, a new account is created via the API and usable to the user The design goals of the tool will be: - help users to get started - have an accessible sign up flow - i. e. no visual captcha - require a certain amount of time (i.e.. no fast clicking through pages) to make mass-account-creation e.g. for spamming unattractive (maybe 3.5 to 5 minutes?) - customize the tour to keep it relevant for users, allow them to skip some potentially boring / irrelevant sections It will require some work, but I am sure that it solves a lot of problems and is a good investment. Open questions of mine: - where will we verify the email? Maybe send the email during the process to reduce waiting time, but not immediately at the beginning to prevent mass-mailing foreign mail addresses? - is explicit waiting time acceptable? I think it is - even if an existing user needs a second account (e..g. for a bot), investing five minutes once is probably okay, while it is hopefully not for spammers
  1. "boring / irrelevant sections" should include questions that specifically looks like (algorithm and user interface) personalisation questions. If these questions are not skippable (like Fandom asking "are you a kid or adult" and that cannot be closed) this may deter normal users.
  2. You would not want to delay with pure JavaScript and static questions without any sort of human verification because bots can (rather easily) quickly click-through no matter how hard you try on the client side. Unless you are confident that most if not all spammers are human spammers then you can ignore this section.
1. "boring / irrelevant sections" should include questions that specifically looks like (algorithm and user interface) personalisation questions. If these questions are not skippable (like Fandom asking "are you a kid or adult" and that cannot be closed) this _may deter normal users_. 2. You would not want to delay with pure JavaScript and static questions without any sort of human verification because bots can (rather easily) quickly click-through no matter how hard you try on the client side. Unless you are confident that most if not all spammers are human spammers then you can ignore this section.
Author
Owner
Copy link

Most spammers are human, and we should try to ensure that the backend keeps track of how fast a user clicks through a page. Also, if we make clear that spam will be removed quickly, we might reduce the attractiveness of abusing our service.

Also, we could do rate limiting in this software. We once had the idea to deploy mCaptcha which would have used proof-of-work and adjusted this automatically to how many registrations we have (e.g. in a case of a spam wave, everyone would need to wait longer for a registration). We could try to include similar mechanisms in the software in the future, e.g. extend the waiting length if there was already an account registered with the same IP recently.

Most spammers are human, and we should try to ensure that the backend keeps track of how fast a user clicks through a page. Also, if we make clear that spam will be removed quickly, we might reduce the attractiveness of abusing our service. Also, we could do rate limiting in this software. We once had the idea to deploy mCaptcha which would have used proof-of-work and adjusted this automatically to how many registrations we have (e.g. in a case of a spam wave, everyone would need to wait longer for a registration). We could try to include similar mechanisms in the software in the future, e.g. extend the waiting length if there was already an account registered with the same IP recently.
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
2 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#1329
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?