xwiki-devs February 2017

xwiki-devs@xwiki.org

14 participants
36 discussions

[xwiki-devs] [proposal] Process to handle Pull Requests

by Ludovic Dubost

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

5 years, 10 months

[xwiki-devs] Velocity 2.0 and DeprecatedCheckUberspector

by Claude Brisson

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

6 years, 9 months

[xwiki-devs] [Vote] Assignee for PR: Contributor or Committer?

by Ecaterina Moraru (Valica)

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

6 years, 10 months

[xwiki-devs] [Proposal] Entry point for Extensions

by Vincent Massol

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

7 years, 7 months

[xwiki-devs] [VOTE] Move from our mailing lists and use Discourse instead

by Vincent Massol

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

7 years, 10 months

[xwiki-devs] [GSOC] XWiki has been selected as a Google Summer of Code 2017 mentor organization !

by Thomas Mortagne

Hi XWikiers, Good news, this year again XWiki has been selected as mentor organization ! The next step is for mentors to register to https://summerofcode.withgoogle.com/ as ask to be mentor for XWiki project (admins can also send invitations). Also don't hesitate to add more proposals on http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/ (there is only proposals from two mentors right now), more details or co-mentor existing proposals. Some students already started to communicate with the community which is great so continue and read http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines to have a better idea of how to get more chance to be selected by XWiki mentors. Good GSOC 2017 ! -- Thomas Mortagne

8 years

[xwiki-devs] Page Complexity limiter

by ktc

Devs, In MediaWiki there are preprocessor limits <https://en.wikipedia.org/wiki/Wikipedia:Template_limits> that track how complex a page is so that rendering can gracefully bail out if any of these limits are broken to keep the server stable. MediaWiki will include this information in a comment in the rendered page like:  We have cases where our users will want to include pages as templates into other pages and these can get pretty deeply nested as well as contain some complex content that is expensive and/or takes a long time to render. We want to make sure that a user cannot bring our servers down accidentally or intentionally due to using too many expensive/long running inclusions on their pages. Testing this on our instance of XWiki is showing that XWiki will run until a) the page is finally able to render which could be minutes in some cases or b) the server runs out of memory and falls over. I have been looking but have been unable to find if XWiki has this sort of feature to turn on and configure. I was also unable to find it in the XWiki Jira or in this forum so I wanted to ask the Devs directly. Does this sort of limiting exist on XWiki? And if so, how can I turn it on? Thanks! -- View this message in context: http://xwiki.475771.n2.nabble.com/Page-Complexity-limiter-tp7602880.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

8 years

[xwiki-devs] [ANN] XWiki 9.1 released

by Vincent Massol

The XWiki development team is proud to announce the availability of XWiki 9.1. This version contains mainly CKEditor integration, HTML export and Job REST API improvements. In addition the Page deletion UI has been made safer to prevent accidental deletion of extension pages. 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.1 Thanks for your support -The XWiki dev team

8 years

[xwiki-devs] [Proposal] Implement a Notification Center

by Guillaume Delhumeau

Hello XWikiers. In the current roadmap, I have the responsibility to create a notification system. The need has been described in the following page: http://design.xwiki.org/xwiki/bin/view/Proposal/NotificationSystemforApps In a few words, applications need to send some messages that could be displayed either on the top menu (the "notification" menu we already have and where the Watchlist options are located) or by e-mail. Users should see quickly the new messages and have the ability to mark some messages has read. Use-cases: having a notification when a new message has been posted on the Forum application, having a notification when the user has been invited to join a wiki, having a notification when a new meeting is organized, etc... Users will also have the ability select which type of notifications she wants to receive. Displaying messages is not the difficult part. Neither is sending emails. What is complicated is the storage of them. Since a user should still see messages she marked as read, we need to store the status of each notification for each user. It could be done either on the server-side (in a NotificationUser table), either on the client-side (using local storage: https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage). I actually see 3 ways to implement the storage: A - When a notification is sent, a job creates all the NotificationUser entries needed (1 per user) with the status "unread". =============================================================================== Pros: * It's quick and easy to retrieve the list of notifications when a user requests a page: all we have to look at is the NotificationUser entries. Cons: * The creation of NotificationUsers entries could take time so notifications will not really be in real-time. * With a lot of users, it creates a LOT of NotificationUsers entries. To avoid having a delay between the sending of a notification and the displaying of it, we can have an in-memory storage in addition to the database storage, which store notifications until they are written in the database. Note: of course, old notifications (even unread) are periodically removed from the database to limit disk usage. B - Create the NotificationUser entries lazily ============================================== When a user requests the list of notifications, we actually look at all notifications and see if they concern the current user. Then, we create NotificationUser entries if some of them are missing. Pros: * In a wiki with a lot of inactive users, we actually store less NotificationUser entries. Cons: * Everytime a user requests the list of notification, we actually need to do the business logic of collecting notifications for the user (more CPU used). C - Store the status on the client-side ======================================= When a user requests the list of notifications, again we look at all notifications and see if they concern the current user. Then, it's the browser which store the "read" status on its local storage. Pros: * We do not store the NotificationUser entries (that can take a lot of places) Cons: * If user changes its browser, she loses all her notifications' status (maybe not that problematic) * Everytime a user requests the list of notification, we actually need to do the business logic of collecting notifications for the user (more CPU used). On this page: http://design.xwiki.org/xwiki/bin/view/Proposal/NotificationCenterforAppsIm… I have explained they way I consider the implementation. There is a notion of NotificationType for example that might interest you. I'm hesitating between option A and C. I think B has no really benefits. The rest of the mechanism can be implemented right away, so I'm starting it. Please answer quickly if you think I am doing something wrong. What do you think? Thanks -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

8 years, 1 month

Re: [xwiki-devs] [xwiki-users] [UX] Administration Improvements

by Ecaterina Moraru (Valica)

Hi Denis, Thanks for your feedback. On Thu, Feb 23, 2017 at 1:38 PM, Denis GERMAIN <dt.germain(a)gmail.com> wrote: > We are running multiple flavors of Xwiki including 7.4.4 (production), > 8.4.4 and 9.0 > > 1. what sections are always needed and maybe we could prioritize them; > Users and Groups are the most heavily used menu in administration for us > We also rely heavily on Import/Exports > > 2. what sections could be grouped together, since they are related; > > 3. what sections are not relevant and could be removed (maybe because they > are too technical, or not needed or rarely used); > Creating subwikis is sometime used so it shouldn't be dropped (for us) > Templates are not often used but really important to us > > 4. if there are important recurring things missing from administration; > There is no easy way to troubleshoot users rights on a page. In other > words, sometime users set rights on "pages and children" OR "pages", and it > causes all sort of trouble > - some users can't see some pages but they should (due to misconfiugration > of the rights) > - some users can open pages with the direct link but can't navigate to it > a) I don't see why there is 2 types of rights on a page, I would personnaly > keep only "pages and children" rights and drop "page only" rights > This is when you need to make exceptions: you want all the children to behave in a certain way, but the parent or a certain subpage to have different rights. I agree it's a more marginal use case, but still it could happen. > b) To troubleshoot, I'd like to have a way to see why some users can see > the page and some don't, or to help me find where the problem is > I agree the rights inheritance is problematic and yes we should improve it (in terms of setting it and display the applied rules). This functionality gets outside of the scope of this Administration reorganization/simplification, but it's indeed very important (and apparently a common problem). > > 5. other ideas? > I find the Template creation (with provider) procedure counter intuitive. > Maybe it could be simplified ? > We added some new functionality in terms of visibility and creation restrictions for templates, but they were intended more as powerful features, we didn't focus on simplifying the process. Yes, we could do some improvements there too, especially since we have started promoting Templates more. Thank you so much, Caty > 2017-02-23 11:28 GMT+01:00 Ecaterina Moraru (Valica) <valicac(a)gmail.com>: > > > Thanks Stéphane for your answer. It's very helpful. > > > > Caty > > > > On Thu, Feb 23, 2017 at 12:15 PM, Stéphane LASSIRE < > slassire(a)cesap.asso.fr > > > > > wrote: > > > > > Hello, > > > > > > What a nice idea. > > > We are using a Xwiki 7.4.4 release. > > > > > > 1. what sections are always needed and maybe we could prioritize them; > > > -> Users / groups / right access / extensions / statistics > > > > > > 2. what sections could be grouped together, since they are related; > > > -> Configuration / Look / Email > > > > > > 3. what sections are not relevant and could be removed (maybe because > > they > > > are too technical, or not needed or rarely used); > > > -> wikis (we are using only 1 instance, so no need of multi configs for > > us) > > > > > > 4. if there are important recurring things missing from administration; > > > -> rights "inspector", not really to know the right of a page inside a > > > space > > > for all users and groups > > > -> activity of a group / user. I try to put a counter inside pages to > see > > > if > > > it is accessed but it a basic solution. I would like to see how much > some > > > pages are viewed. The statistics are limited on this part > > > > > > 5. other ideas? > > > -> see 4 > > > > > > Thanks > > > > > > Cordialement > > > > > > Stéphane Lassire > > > Chargé de l'informatique et de la communication > > > Courriel : slassire(a)cesap.asso.fr > > > > > > -----Message d'origine----- > > > De : users [mailto:users-bounces@xwiki.org] De la part de Ecaterina > > Moraru > > > (Valica) > > > Envoyé : mardi 21 février 2017 16:15 > > > À : XWiki Mailinglist; XWiki Mailinglist > > > Objet : [xwiki-users] [UX] Administration Improvements > > > > > > Hi, > > > > > > We are thinking about improving the Administration, so would be great > to > > > hear your opinion about: > > > 1. what sections are always needed and maybe we could prioritize them; > 2. > > > what sections could be grouped together, since they are related; 3. > what > > > sections are not relevant and could be removed (maybe because they are > > too > > > technical, or not needed or rarely used); 4. if there are important > > > recurring things missing from administration; 5. other ideas? > > > > > > We are particularly interested in 1. and that is sections that are used > > > often and would love to know which are those (since they differ so much > > > depending on usage). > > > > > > Let us know, > > > Caty > > > > > >

8 years, 1 month

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs February 2017