April 2017 - xwiki-devs@xwiki.org

[xwiki-devs] [proposal] Process to handle Pull Requests
by Ludovic Dubost 10 May '19

10 May '19

Hi devs, I don't think there is currently a process that is in place to handle pull requests and I have the feeling that the way there are handled today is a bit random. There are usually comments sent out on each pull request but sometimes it seems that some pull requests are going in sleep mode and it's not clear who is in charge. I would like to suggest that a process is put in place where it's clear who is responsible for a pull request and a status is given to the contributors that propose that pull request. Something like: Assigned developer: XXXX Status: New -> new pull request, not yet assigned Assigned -> assigned to a developer, he is in charge of reviewing the pull request and ask for modifications or accept it. The developer can auto assign it to himself. If nobody does, we need to decide how they will be taken into account. ModificationsRequired -> for now rejected with comments. Contributor needs to apply comments and then change back to Assigned for further evaluation VoteRequired -> there are no more comments, but a vote is required as the changes to XWiki core are important WaitingFinalAuthorization -> optional step for complex patches where a additional authorization would be required (need to define who would be the persons that give the authorization) WaitingApplication -> there are no more comments and no changes or vote required. The pull request can be applied and is waiting for a developer to apply it Abandoned -> contributors is abandoning the pull request (cannot do the changes, no more time, etc..) Rejected -> pull request is rejected (quality not enough, etc..) Applied -> pull request is applied What do you think ? Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

7 12

[xwiki-devs] Velocity 2.0 and DeprecatedCheckUberspector
by Claude Brisson 20 Jun '18

20 Jun '18

Hi. I'm currently working on Velocity 2.0 packaging. If that's OK with you, I would like to incorporate DeprecatedCheckUberspector.java into Velocity, but I need a statement from your part to be able to change its licence to Apache 2.0 (LGPL and Apache 2.0 licences aren't compatible). By the way, I take this opportunity to tell you that if there is another specific part of xwiki-commons-velocity that you think should be integrated on our side, or an important missing feature you'd like to insist on, don't hesitate. I already integrated VELOCITY-825, for instance, so String->Enum constant conversions are now handled by Velocity. There may be other important conversion cases you'd like to see handled. Regards, Claude

4 8

[xwiki-devs] [Vote] Assignee for PR: Contributor or Committer?
by Ecaterina Moraru (Valica) 07 May '18

07 May '18

Hi, We have discussed this subject multiple times, but we don't have an official vote and conclusion on the topic. Problem: In JIRA who is the Assignee of an issue fixed by a Pull Request? 1: Contributor - he provided the solution - giving the attributions, the contributor might feel encouraged to contribute more - we could do some JIRA statistics on external contributions, but this use case can be covered by GitHub statistics 2: Committer - he does the merging on his account and he becomes responsible for the committed code. - in case there are problems, the committer needs to find solution, since we can't rely on contributors availability - in doing the PR review, the committer spends a lot of time analyzing and testing the provided solution We are talking here about complete solutions provided by the PR, since in case of partial solutions, the committer can assign himself on the issue (depends on the quantity of modification he does). Let me know what you think, Caty

9 11

[xwiki-devs] [Proposal] Entry point for Extensions
by Vincent Massol 18 Aug '17

18 Aug '17

Hi devs, Problem ======= We have 2 issues right now when installing an extension in XWiki: 1) It’s not clear where is the entry point of that extension. - Example1: an app that is only for admins and only has a ConfigurableClass - Example2: an app that provides a macro and doesn’t have a UI 2) Even when an extension registers itself in the Applications Panel, the user still need to refresh the page or navigate away to see it. Proposal ======== * Introduce the concept of Entry point (a.k.a home page) in Extension metadata * Have the EM UI display the extension’s entry point (when there’s one) after having installed the extension so that the user can click on it and be taken to the home page of the extension. This would make extensions more discoverable IMO. Implementation Details ================== * Some maven extension metadata properties in pom.xml * A format to represent an entry point. It shouldn’t be a full URL since that needs to be computed at runtime. Basically it should contain: ** The document reference ** The action to use (view, admin, etc) - optional, should default to “view" ** The query string to use - optional, should default to an empty query string This corresponds to the notion of ResourceReference (EntityResourceReference to be precise). However we don’t have any textual representation of it ATM. WDYT? Good idea? Bad idea? Thanks -Vincent

8 16

[xwiki-devs] [VOTE] Move from our mailing lists and use Discourse instead
by Vincent Massol 15 May '17

15 May '17

Hi devs, I’m proposing to vote for moving away from our users and devs mailing list and instead to use the Discourse open source tool: * Home page: http://www.discourse.org/ * License: GPL v2 * FAQ: http://www.discourse.org/faq/ * Awesome feature list: http://www.discourse.org/about/ What is especially interesting for us: * It works with mailing lists (you can receive mails and send mails to the forum). * Works as a forum. BTW if you want to see a real life instance, check the gradle instance at https://discuss.gradle.org/ Nice things: * Works on mobile * Comprehensive API (would allow us to integrate it with xwiki.org) * Badges/user metrics So here’s my +1 to try it out and ask XWiki SAS if they could host an instance. WDYT? Do you see any negative point (I don’t ATM)? :) Please cast your votes! Thanks -Vincent

10 30

[xwiki-devs] [Proposal] Create a separate IRC channel for notifications
by Vincent Massol 12 May '17

12 May '17

Hi devs, I think we’ve reached the point when we need 2 IRC channels: * one for users and devs discussions (“xwiki”) * one for notifications (“xwiki-notifications”) There are too many notifications right now to be able to have unobstructed conversations on IRC. Note that ideally this will require modifying the IRCBot application so that some Botlets are on the main “xwiki” channel (like the the jira botlet that gives the full URL of a jira issue) and the others on the “xwiki-notifications” channel. However, FTM I’m proposing to configure the IRCBot to use the xwiki-notifications channel exclusively. WDYT? Thanks -Vincent

5 8

[xwiki-devs] [XWiki Day] BFD#141
by Alexandru Cotiuga 28 Apr '17

28 Apr '17

Hello devs, Today is BFD#141: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 500 days period is 60 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=103 52#Created-vs-Resolved-Chart/16742 Here's the BFD#141 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13891 Happy BugFixing Day, Alex

1 1

[xwiki-devs] [ANN] XWiki 9.3.1 released
by Thomas Mortagne 26 Apr '17

26 Apr '17

The XWiki development team is proud to announce the availability of XWiki 9.3.1. This version fix a bug that makes impossible to migrate subwikis and a regression related to escaping in requests LIKE values. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/9.3.1 Thanks for your support -The XWiki dev team

2 1

[xwiki-devs] [Proposal][UX] Explicit content actions
by Ecaterina Moraru (Valica) 25 Apr '17

25 Apr '17

Hi devs, Some users have complained that the content actions are too abstract / ambiguous and they don't see/understand them so they don't know how to Edit or Create content in the first minutes of interaction. More details about this problem can be found at http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaLabeledActions There I've suggested 2 possible proposals: Proposal 1: JS Tooltips Proposal 2: Labeled actions Which one do you prefer? Thanks, Caty P.S: This was a recurrent topic and we change several things over the years. I guess we will continue iterating until we reach the sweet spot :)

7 17

[xwiki-devs] [Proposal][UX] Visible Save buttons
by Ecaterina Moraru (Valica) 25 Apr '17

25 Apr '17

Hi devs, Some users have complained that when editing they don't know that they need to scroll in order to see the Save buttons. This is a proposal that tackles: - Displaying the save buttons in a bottom area, when they are out of the viewport, see http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/bottomB… - Reorganizing the bottom zone in order to compact all the save functions into a single bar - When the user scrolls, the buttons go into their position, see http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/after.p… For the whole proposal and more screenshots, see http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaVisibleSave WDYT? Thanks, Caty

6 16