Spec:
There are two kinds of user groups: organizations and groups.
Organizations behave like users and have the % prefix. They can own repositories and live in a global namespace.
Groups are a group of users and/or organizations and have the ^ prefix. They can be assigned to ACL entries and live in a private namespace, under a single user/group.
This allows you to, for example, establish an organization for a larger project, like %swaywm, and fill it with groups of users with different permissions. These can be referred to like %swaywm^committers, %swaywm^triage, %swaywm^subproject, etc. These can be filled with different sets of other users and ACLs configured appropriately, such as giving %swaywm^committers push access and letting %swaywm^triage some extra permissions on the bug tracker.
You can also establish groups underneath a user, like ~sircmpwn^friends. You can refer to such groups with the ^friends shorthand, your username is implied. These can be used to make combined profile pages, such as git.sr.ht/^friends, and used in ACLs just like groups underneath an org.
Organizations would be really handy for lists and git.
+1 for Organisations, very important for multi developer open source projects. So the project doesn't appear to be 'owned' by a single developer.
In the context of the bitbucket-mercurial exodus, allow me to note that indeed, organizations would be very welcome. Is there a chance to see this before the complete shutdown ? It would help avoid relocating to temporary uris.
This could be handy for grouping sets of projects, by language or topic under a user account.
Apart from that, it would be nice to have the ability to transfer the project from the user to an organization out of the box, so the migration from the existing repositories will be easier.
Is there an ETA for this feature getting public (beta-testers maybe)?
I imagine sourcehut would also end up under an organization?
How will pricing work? Will organizations be subject to the same pricing model as users?
Prefix nonos
%
is probably a bad idea because browsers assign special meaning to it (%20
)^
is probably a bad for zsh reasonsOn the mailing list0 I believe you narrowed it down to
.-_~!&*+=
I like & ;)
Have there been any updates on this issue?