Install Change Request on xwiki.org

Development
1

Hi,

following the developer meeting this afternoon and the discussion about the documentation refactoring on XWiki.org I’d like to propose to install Change Request on www.xwiki.org.

The way I see it, the extension should be installed on the following wikis:

  • main wiki
  • dev
  • contrib
  • rendering
  • commons
  • cristal

I’m not sure about installing it in:

  • extensions
  • design
  • test
  • snippets

for the reason that those wikis are mainly used to edit xobjects: it’s supported in change request, but the diff might be more complex. wdyt?

Regarding the configuration of CR, I would give the rights to “Request Change” (i.e. create a CR) to any logged in user (XWikiAllGroup): guests wouldn’t be allowed to use that feature to start.
Then I would give the rights to Approve Change to the following groups:

  • XWikiAdminGroup
  • XWikiCommittersGroup
  • XWikiContribCommittersGroup
  • XWikiPowerUsers

And finally, I would configure the extension with following values:

  • Publication Approval Strategy: Require only approvals. This strategy allows to publish the requested changes when there’s at least one review and all reviews are approvals. The idea here is a single reviewer is enough, but anyone blocking approval would block merging the changes. For details about possible strategies see: https://extensions.xwiki.org/xwiki/bin/view/Extension/Application%20Change%20Request%20-%20UI/#HApprovalstrategies
  • Prevent authors from reviewing Change Requests they create: yes, I would use that configuration since IMO if you create a CR you should have a review even if you have rights to publish it
  • Enable the rendered diff view: yes, I would check it since IMO it simplifies the review
  • Only accept approvers that have the approval right: yes, I would check it: currently the UI is not clear enough that providing a list of approvers is optional when creating a CR (I will open a ticket for that usability issue) so IMO it will avoid problems to check it

For the other configurations I would keep the default:

  • Change Request Storage Location: ChangeRequest.Data (default)
  • Publication user: none defined (default), fallback on the user clicking the publish button
  • Open Change Request timeout: 20 days (default), that’s the delay before moving from open to stale
  • Stale Change Request timeout: 5 days (default), that’s the delay before moving from state to close
  • Use creation date for timeouts: no (default) it would use the date of latest change in the CR
  • Scheduled job user: none defined (default), it’s the user who installed the extension which would be used
  • Enable delegate approvers: no (default)
  • User properties to use for computing delegates: none (default) - doesn’t apply if we don’t use delegate approvers
  • Minimum number of explicit approvers: None defined (default)
  • Security policy to use for the rendered diff: default policy (default)

If you want details all the administration options are documented in https://extensions.xwiki.org/xwiki/bin/view/Extension/Application%20Change%20Request%20-%20UI/#HAdministration

wdyt?

2

For me, if we install CR on xwiki.org we need it on all wiki (especially on extensions since it’s the wiki with the most documentation and changes and the future doc improvement proposal will make it even more important for doc).

Now, WDYM by more complex? Why would the diff be more complex if I change an xproperty of type, say, TextArea vs if I change the content of a page?

Thanks

3

Well no if the change is only about the TextArea property, then the diff should be indeed the same.
To be honest I haven’t much experimented using CR with xobjects, so I’m expecting a bit some limitations. But we can give it a try, and it will probably be a good test to improve it I guess.

4

+1 to try it and learn from it. FTM we should keep both “Save” and “Save as CR”.

BTW what happens when we upgrade to XWiki 17.3.0 with the new Realtime edit toolbar? Where is the CR button in the new action toolbar? Was this tested?

I guess every person in the groups mentioned will need to activate notifications, right?

I trust you on the param configuration for now and we can fine tune later if need be.

Thx!

5

Yes, I haven’t made it explicit in my proposal but I’m not planning to change current existing edit rights.

So I just checked on an instance and indeed there’s a breakage: since realtime is enabled by default we cannot use “save as change request” and it actually doesn’t make sense with autosave… I’ll open a ticket. [Edit: actually I had opened Loading... in the past which is about the same topic]
It won’t impact xwiki.org though since realtime is disabled and so it fallback on old edition.