Tour for new users #1329

New Issue

Open

opened 2023-11-02 10:35:08 +00:00 by fnetX · 2 comments

fnetX commented

2023-11-02 10:35:08 +00:00

Owner

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

👍 2

fnetX added the

contribution welcome

service

Codeberg

labels 2023-11-02 10:35:25 +00:00

WithLithum commented

2023-11-04 01:20:53 +00:00

"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.
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.

fnetX commented

2023-11-04 09:07:16 +00:00

Poster

Owner

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.

👍 1