Commit 098ccc80 authored by Georges Racinet's avatar Georges Racinet 🦑
Browse files

FAQ: rewrote the answer about personal forks

We don't want to give the impression that we don't care about
drive-by contributions. In fact, we've given them some serious thoughts
lately.

Closes #20.
parent 8bed6a4d2f06
Pipeline #29613 passed with stages
in 3 minutes and 1 second
......@@ -303,5 +303,7 @@
Does Heptapod have personal forks?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Not for the time being, but we need them less than in regular GitLab.
Personal forks are currently available only for Git projects, but we
plan to improve on that in the future. Please
read below for more about making contributions easier for Mercurial projects.
......@@ -307,8 +309,20 @@
In practice, not having forks means that all contributors to a project
have to be granted the right to push topics to its main repository.
In Heptapod, this is the Developer role, which does *not* have the
`right to push to named branches by default`__.
We acknowledge the importance of personal forks, especially for the
purpose of so-called "drive-by contributions," and it's on our
roadmap, but we haven't gotten to it yet. Our current plan is to take
an incremental approach, and as the first step, support drive-by
contributions without requiring a grant of permission. We plan to do
this before we introduce personal forks proper.
Not having personal forks is a bit less problematic with
Mercurial projects than one could fear: on one hand, all contributors
to a project have to be granted the right to push topics to its main
repository. On the other hand, this corresponds in Heptapod to
the Developer role, which does *not* have the
`right to push to named branches by default`__. We realize that the
necessity for contributors to request a grant of permission is
unwanted friction that we need to resolve.
__ publish_perm_
......@@ -312,9 +326,21 @@
__ publish_perm_
We are thinking about supporting personal forks, but we want to do it the
right way, so that the chosen solution is transparent for users, and
robust enough to serve us in the long run.
Our nearest term plans to foster easy contribution consist of
implementing `user namespaces for topics
<https://www.mercurial-scm.org/wiki/TopicPlan#sub_branches.2C_namespacing_and_representation>`_.
Users with enough rights to open an Issue on the Project would also be
allowed to push changesets with topics in their own namespace.
More specifically, the required role will be `Reporter
<https://docs.gitlab.com/ce/user/permissions.html#project-members-permissions>`_.
This role is granted by default on public projects to all
authenticated users.
At that point, personal forks wouldn't really be necessary, but they
would still be the basic UX expectation, especially among new users.
We will therefore proceed to implement them, but that is more
difficult to get right and will probably rely under the hood on topic
user namespaces again.
.. _repo_path:
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment