xwiki-devs May 2013

xwiki-devs@xwiki.org

35 participants
77 discussions

[xwiki-devs] [Discussion] Should technical pages hide the bottom tabs?

by Sergiu Dumitriu

Hi devs, For content pages, the bottom tabs (comments, attachments, history, information) are very useful features. But does it make sense to keep those active for very technical pages? For example, when viewing details about a tag, (Main/Tags?do=viewTag), why should people be allowed to comment? They might wrongly think that they're commenting on a tag, but that's just one complex page that handles almost everything about tags, so a comment like "this tag has a typo" doesn't help at all. Other pages should have no bottom tabs as well: user directory, blog category management, the whole scheduler space, share by email... While the homepage is a technical page (by default), it does make sense to leave the comments active, since it's the entry point for every user (although I think that the messaging system is a better way to send global messages). IMO, the advantage is that we're hiding actions that are rarely useful, but could be misused. The disadvantage is that we're breaking the universality of the UI. I'm +1 for hiding, fewer mis-usable features is always better. -- Sergiu Dumitriu http://purl.org/net/sergiu/

10 years, 10 months

[xwiki-devs] [VOTE] New rule: Put ScriptService implementations out of the internal package

by Vincent Massol

Hi devs, We need to solve http://jira.xwiki.org/browse/XWIKI-9157 I'm proposing to simply move all ScriptService implementations out of the internal package and make that a rule. These classes are used by introspection and as such as not used as components and thus they should not be in the internal package. Here's my +1 and I'm proposing to handle the move. I can't think of anything that would break except some users who would have had an import in a groovy script on some internal Script Service but that's ok IMO. Thanks -Vincent

10 years, 11 months

[xwiki-devs] [Proposal] New xwiki-platform-wiki/xwiki-platform-wiki-descriptor module

by Vincent Massol

Hi devs, As you may have seen I've started working again on xwiki-platform-url module (http://jira.xwiki.org/browse/XWIKI-3951) and I now need to add wiki alias support for it. Right now wiki alias support is in oldcore and the url module must not depend on oldcore so I need to extract wiki alias support to a new module. I'm proposing to create a xwiki-platform-wiki module which should contain in the future all modules related to multi wiki handling for stuff not in the model (stuff in the model will go in xwiki-platform-model). Right now I'm proposing to have: xwiki-platform-wiki |_ xwiki-platform-wiki-descriptor where xwiki-platform-wiki-descriptor will implement description of wikis as xobjects in wiki pages (XWikiServerClass), i.e. what is currently in oldcore's XWiki#findServer. In the future the idea will be to rewrite xwiki-platform-wiki-manager and to move it to xwiki-platform-wiki/xwiki-platform-wiki-manager for example (or with another name). WDYT? Barring negative feedback I'll try to start working on this in the coming week. Thanks -Vincent

10 years, 11 months

[xwiki-devs] [Proposal] Finding how many active instances of XWiki there are out there

by Vincent Massol

Hi devs, I think it would be great to have some indication of how many active instances of XWiki are out there in the wild. The idea is not so much to know the figure but to see how this figures evolves and thus to see if we're doing things right. It will also give us information about how quickly or slowly our user base upgrades from version to version. Here's my proposal: * When installing XWiki on a clean DB (ie first time install) generate a unique id and store it in the DB (similar to the version we're storing in the DB but using some UUID). Thus when an install is upgraded the same id is preserved. * When the Extension Manager is used and thus connects to extensions.xwiki.org (default extension repository), this unique ID is sent too. * In addition the version of XE is sent too * On extensions.xwiki.org side, we only log the unique ID/XE version **without** logging the IP or any other information thus ensuring that the ID remains completely anonymous * We display a counter on xwiki.org about the # of active instances of XE with a graph about XE versions used WDYT? Thanks -Vincent

11 years

[xwiki-devs] [Proposal] Add CLA for contributions + Foundation

by Vincent Massol

Hi devs, I'd like to propose the following: * That we start asking for a CLA for contributions (and also for current committers) * That we keep the process lightweight in order to not make it harder to contribute to the xwiki project. For this I propose to use http://www.clahub.com/ In order to understand why we need a CLA read: * http://www.oss-watch.ac.uk/resources/cla * http://en.wikipedia.org/wiki/Contributor_License_Agreement If we agree we then need to define our CLA. I think a good starting point could be the Node.js one: http://nodejs.org/cla.html Now I don't think the CLA will have any legal value if we cannot define "the XWiki project" as a legal entity. Thus I believe we need to start by joining some foundation or creating one. I'll list some easy possibilities: * SF Conservancy: http://sfconservancy.org/members/current/ * SPI: http://www.spi-inc.org/projects/ * Create our own Not for profit association Harder possibilities (need to change license, rename project, etc): * Join ASF * Join Eclipse (and be forced to use bugzilla as the issue tracker ;)) We also need to check if OW2 could offer that service of being a legal entity for XWiki. Personally I'm tempted more by our own association (it's quite easy to create one if we don't need to accept money and a bit more complex if we want to accept money but still doable). My second choice goes to SFC. WDYT? Thanks -Vincent

11 years

[xwiki-devs] [Proposal] Add new API to ModelConfiguration to get the default syntax

by Vincent Massol

Hi, I'd like to add: public interface ModelConfiguration { … Syntax getDefaultSyntax(); } And the configuration key would be: model.defaultSyntax=xwiki/2.1 This also means deprecating CoreConfiguration.getDefaultDocumentSyntax() in oldcore The goal is to have a clean way for getting the default syntax for documents for example without having to use oldcore. I need this to fix http://jira.xwiki.org/browse/XWIKI-9074 for example. WDYT? Thanks -Vincent

11 years, 1 month

[xwiki-devs] [GSOC: mobile client] Welcome to Buddhiprabha Erabadda

by Ludovic Dubost

Hi all, I'd like to welcome Buddhiprabha Erabadda to our community on the GSOC Mobile Client project, which I will mentor. Buddhiprabha Erabadda is our only GSOC student this year as we were not enough satisfied with the quality of the other proposals. No pressure Buddhiprabha. The objective of Buddhiprabha will be to help me getting the best possible XWiki Mobile out the door on Android and iOS, with particularly notifications implemented. We will also work with Caty on her proposals for the mobile app: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MobileApp We will also add improvements to the XWiki REST Api during the project especially to improve performance. There is already a pull request to get more page data in one request ( https://github.com/xwiki/xwiki-platform/pull/111 ) We have a jira project to track tasks: http://jira.xwiki.org/browse/XMMORPHO Welcome Buddhiprabha to XWiki Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

11 years, 1 month

[xwiki-devs] [Idea] XWiki Project Development Flavor

by Vincent Massol

Hi devs, I've noticed Apache BloodHound (https://issues.apache.org/bloodhound/) and this reminded of this idea I've had several times in the past: Creating a Project Development Flavor of XE. I mentioned it in some other email already but I wanted to see if this excites you as much as it does for me and maybe we could brainstorm in this thread about what it could be like . Some scattered thoughts: * First, from the point of view of the XWiki project I believe it could be a game changer if we did it right since it has the potential of being adopted by projects around the world and thus making them discover xwiki as a result. And since they're developers they would be able to take advantage of XWiki's development features and contribute back to the project through extensions for example. * Ideally it would be awesome that this project be started independently of the XWiki project I think and just use XWiki as the platform since it's a full fledged project with a different goal than the XWiki project itself. * We need to finish the Flavor idea by allowing the DM to list flavors. * Some ideas of content for this Development Project flavor: ** A home page dashboard about metrics of your project. These metrics would be retried from external sources. Examples: *** Statistics about commits using Git/GitHub *** Latest emails (taken from mailman or other mailing list software, possibly by subscribing the project to a mailing list so that it gets the emails) *** Latest issues (taken from JIRA for example) *** Screenshot example: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgProposal2#… ** A Release application to help perform releases ** A forum application, for example the Mail Archive Application done by Jeremie which would need to be improved to add ability to post from it ** A Release notes application ** The Blog application ** Ability to generate a whole PDF for the project's documentation for a given version ** A modern and nice skin (either Lyrebird or the new Skin proposal: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4x) ** A layout configured for the flavor ** Future: a simple issue tracker (or integrate one) for those who want an all-in-one solution. However keep the external issue tracker possibility for those already having an issue tracker ** Some predefined templates for creating well known project pages: source repository, build, hall in fame, project documentation home page, etc ** The IRC Bot application ** Bundle the JIRA macro ** Bundle the FAQ application ** A Roadmap application * Of course we should use this flavor on xwiki.org itself. And we could move some of the modules we currently have in platform and that would make more sense there (jira macro, IRC Bot application, FAQ application, etc). WDYT? Add your ideas to this email thread or, better, on http://dev.xwiki.org/xwiki/bin/view/Design/DevelopmentFlavor Thanks -Vincent

11 years, 2 months

[xwiki-devs] [Feedback] Activity Stream

by Ecaterina Moraru (Valica)

Hi, We introduced the Activity Stream macro in XE 2.6 http://extensions.xwiki.org/xwiki/bin/view/Extension/Activity+Macro We are investigating ways to improve our Activity Stream, but in order to do that we would want to know your feedback about it (both from a technology and an user experience pov): - Is Activity Stream a macro you use? - What features you most miss about it? Maybe filtering? Maybe pagination? - Would you like to see more event types, like events generated by applications? - Are you using the "Send Message" functionality? - Other opinions about it. Your feedback will help us improve the macro by adding needed functionality and not breaking used one. I'll gather ideas on http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActivityStreamFeed… Thanks, Caty

11 years, 2 months

[xwiki-devs] [Proposal][QA] Put Test Report Application on xwiki.org

by Sorin Burjan

Hello everybody, After several months of fragmented work, I have finally managed to complete the next iteration of Test Report Application [1]. Final parts of the code will be committed next week. Taking into consideration the feedback I received, I implemented several changes into the application to make it more user friendly and robust. In order to put the application in production, Manuel and me converted the Manual Test Report Template [2] into Test Cases to be used by the Test Report Application. These test cases are committed on Github [3]. Now we have 404 Test Cases, grouped in 22 Spaces as follows: 1) Action Menus Tests 2) App Within Minutes Tests 3) Dashboard Macro Tests 4) Page Tabs Tests 5) Rights Tests 6) Tags Tests 7) Wiki Editor Tests 8) WYSIWYG Editor Tests 9) Activity Stream Tests 10) Blog Tests 11) Document Index Tests 12) Panels Tests 13) Search Tests 14) User Profile Tests 15) Wiki Manager Tests 16) Administration Tests 17) Color Themes Tests 18) Jump To Page Tests 19) Register and Authentication Tests 20) Space Macro Tests 21) User Status Tests 22) Workspaces Tests My proposal is that we create a dedicated subwiki for this, qa.xwiki.orgwhere we will deploy the application + test cases. The rationale behind having a dedicated subwiki for this is that we don't want to crowd an already existing subwiki with the test cases and also the spaces which will hold the test execution pages. WDYT ? I am waiting for your opinions/concerns/questions about this. Regards, Sorin B. [1] https://github.com/xwiki-contrib/application-testreporting [2] http://www.xwiki.org/xwiki/bin/view/TestReports/ManualTestReportTemplate [3] https://github.com/xwiki-contrib/application-testreporting-cases

11 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs May 2013