Change Request: who can participate to an existing change request?

Development
#1

Hi everyone,

as you might know I’m currently actively working on the Change Request extension, and I have an open question about allowing people to participe on existing change requests.
So on the following, I will only consider Change requests that are already created, and I consider that the first person who creates the change request is the original author.

Now, nothing prevents a Change request to be authored by multiple people, bringing different contributions on same documents or on different documents. To bring a bit more context, you should however know that the people who author a change request cannot approve them by themselves. So only external people of a change request (who are not author) can approve, and those approvals might be required for merging (depending on the chosen merging strategy).

Also consider that several edition activities can occur on a change request:

  • changes can be performed on documents already added in the change request,
  • changes can be added from documents that are not yet included in the change request,
  • conflicts can be solved
  • changes can be rebased individually on some files, or on all the documents of the change request
  • description and title of the change request can be edited
  • status of the change request can be changed, to mark it as draft, or ready to review, or to even close it

So based on all those information, my question is: for those existing change request, do we allow any people who has proper rights to create a change request, to also edit the existing ones to perform the activities I just mentioned?

AFAIK when you create a pull request on Github, if you are committer of the original repository then you are able to perform commits on the branch of the creator of the PR, so basically you can edit the created PR to add changes. I think you can even edit title and description, and for sure you can close it.

So right now I see different solutions:

  1. we authorize anyone who can create a CR, to participate to any existing CR by performing the activities I mentioned, in which case for all the mentioned activities the user is added to the list of author and cannot approve the CR anymore (and if there’s an existing approval, it would be outdated automatically, to not consider it)

2a. we only authorize the original creator to edit their own CR, nobody can perform any changes on them, so they will be always the only author and any CR can only have a single author

2b. we only authorize the original creator to edit their own CR for a subset of the activities such as editing description / title / status and adding changes from other documents. We authorize other people to solve conflicts / rebase and add changes concerning the already added documents: in such case, those people become authors of the CR, on same condition than in solution 1.

  1. we let the author of the CR to decide if it should be closed or not, and we let them the capability to invite people to participate to a CR.

Note that for solution 3, we cannot give a CR author Admin rights on the CR automatically to handle that, since if we give admin rights it means the user would be able to bypass the approval mechanism in the CR.

WDYT?

#2

I don’t think that’s a good idea. In the same way that I can create a GitHub PR and apply it, I should be able to create a CR and approve/apply it. At least that should be the default to me.

Since anyone with edit rights on a page can edit it, anyone with edit rights on the CR page should be able to edit them, and by default anyone should have edit rights on all pages. The rationale is that a CR is just a delayed way of modifying content.If the content was added directly then users with edit rights would be able to change them. So the same should be doable for CRs. At least by default.

PS: I just read the question and didn’t fully read the different solutions proposed (didn’t read below “AFAIK when you create a pull request on Github”). I wanted to provide a first opinion quickly.

#3

That’s logical since if I have edit rights, I can edit the content directly.

#4

I’m changing my response above. As Thomas said:

A CR is a proposal for a change that you generally want to own IMO. Collaboration is a document thing while change request should be personal by default.

That’s indeed right since otherwise there would be no need for CRs :slight_smile:
Said differently, the introduction of CR is indeed to avoid the collaboration part!

So I agree that it should be personal by default and let the CR author(s) decide.

#5

Hi everyone,

I’m reopening this topic because I have one problematic usecase: how to handle CR created by guests?
To be clear, right now I’m using in change request the following proposed solution:

with some minor exceptions if a user has admin rights. And the idea is to later improve this, to allow the author chose to open it or not.

Now the problem is that I don’t know how to handle this if the author is guest: do we consider that a CR created by guest user can be edited by everyone?

#6

I guess it’s the current behavior ? Honestly, IMO, it’s good enough for a 1.0 at least.

I can only think of two alternatives to that:

  • identify a specific guest user (or more accurately, a specific HTTP client) which probably mean generating some unique ID put in a cookie
  • forbid guest users from creating change requests
#7

Well, right now any Guest user can edit it (logged in user cannot), but I consider it’s a bug and I’ll create a ticket to fix it.

That’s the only other solution I can think of, but sounds pretty dangerous: if for some reason the user clean the browser cookie and we only allow them to edit the CR, it means we could have many CR “stuck”. It’s mitigated by the scheduler put in place to mark CR as stale though.

So actually maybe it’s not that bad.
So I propose the following:

  • in v1.0, everybody can edit them
  • in v2.0, we have the capability for standard users to chose to open CR for other authors. On the same idea, we put an option to allow guest users to close their CR: in such case we put a cookie on their browser so that only them can edit it. And this entire behaviour can be switched off by admin.

This is actually a requested feature for CR to be able to edit with guest.

#8

Yes, I assumed, just wanted to list all possibilities.

Note that it could still make sense to have an option for someone who would like to disable CR created by guest users. I can perfectly understand that someone would not want that: reviewers don’t really know who they are talking to, guest users won’t receive any notification about the CR they created (if there are comments, etc.). I would definitely advocate for it for xwiki.org use case for example, for the same reason we don’t let guest users comment freely.

#9

It’s already a supported feature since change request is enabled through a right: so you can deny the right for creating change request to unregistered users.

#10

Indeed, I missed that part (or probably more accurately forgot about it).