recurse-community-portfolio icon indicating copy to clipboard operation
recurse-community-portfolio copied to clipboard

Multi-author projects

Open jasonaowen opened this issue 5 years ago • 2 comments

Allow projects to be authored by multiple people.

This raises a surprising number of questions and edge cases:

  • can any author add any other author?
  • can an invited author decline?
  • can an invitation be revoked before it is accepted?
  • how is the invitation status shown?
  • how is an invited author notified? in the app? via email? via Zulip? via a unique URL that the inviting user has to share out-of-band?
  • can a Recurser who has never logged in be invited?
  • can an author remove another author from a multi-author project?
  • can one author of a multi-author project delete that project?
  • more broadly, do all authors have equal permissions on the project? if not, what sets of permissions exist?

jasonaowen avatar Apr 25 '19 16:04 jasonaowen

I've been thinking about this for a few weeks. I want to balance privacy, clarity, and ease of implementation. Here's what I propose for now:

  • A project is initially created by a single author, and can invite additional authors at creation or by editing the project.
  • Invitations can be declined, and once declined cannot be re-invited for that project.
  • The author(s) of a project can see invited co-authors, as can the invited author before accepting, but no one else can.
  • Once an invitation has been accepted, only that author can remove themself from a project; authors cannot remove one another.
  • An author cannot delete a multi-author project; they can only remove themself. A project must have at least one author, which means that an author cannot remove themself from a single-author project; they can only delete it.
  • All authors have equal permissions to edit a project. This passes the risk of inviting a malicious user on to the inviting user, but RC is a comparatively low-risk environment, and presumably people made this risk assessment as part of working together.

jasonaowen avatar Apr 25 '19 16:04 jasonaowen

@blinry raised the question of listing non-Recurser co-authors, and I think for now my answer is "put them in the description," for a few reasons.

Mainly, I don't want to add another type of authentication, which would be required to create user accounts for non-Recursers. Additionally, while I definitely want to make room for projects created by Recursers outside of an RC batch, I think my emphasis here is on Recursers and their work.

Crediting non-Recurser co-authors in the description of a project feels to me like it strikes a reasonable balance.

jasonaowen avatar Apr 25 '19 16:04 jasonaowen