[xwiki-users] try it online link doesn't work
The link try it online doesn't work here: http://enterprise.xwiki.org/xwiki/bin/view/Main/ It links to xwiki.com, is it correct? Can also somebody place the contribution link there? http://dev.xwiki.org/xwiki/bin/view/Community/Contributing Then all the important things would be together: docs, download, try it online, contribution. Thanks, Roman Am Sonntag, den 18.10.2009, 17:11 +0200 schrieb Roman Friesen: I have moved the Contribution draft to the original page, many thanks to all helping on that :) http://dev.xwiki.org/xwiki/bin/view/Community/Contributing In my opinion, a link to the Contribution page should be a added to the XE main page as well: http://enterprise.xwiki.org/xwiki/bin/view/Main/ Can somebody place the link there? I don't have the edit rights. P.S. the link try it online doesn't work on the enterprise main page. Regards, Roman Am Dienstag, den 06.10.2009, 23:59 -0700 schrieb Silvia Rusu: Hi Roman, I took the liberty of rephrasing a few things in the text. Hope this helps :) , Silvia Roman Friesen wrote: Hello, I've started work on the Contribution draft: http://dev.xwiki.org/xwiki/bin/view/Drafts/XEContribute Any help/feedback would be very appreciated. Especially as my English skills are not good enough to produce high quality texts. @Vincent: I have seen your improvements, thanks :) First I sent this e-mail on Sunday, but unfortunately from a wrong e-mail... :( Thanks, Roman ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users - Silvia Rusu Tester Documentation Writer - XWiki http://twitter.com/silviarusu ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] [docs] draft: XE main documentation page
Hello, currently the xwiki documentation runs on several wiki instances and spaces. Unfortunately it's not structured well too, so it's really very hard to find required information. It's my experience. I think something like a Table of Content could help indeed. Probably it would be fix dirty solution, but nevertheless a solution. Please look at the current draft for that page: http://dev.xwiki.org/xwiki/bin/view/Drafts/XEDocMain Any feedback/help would be appreciated. Regards, Roman ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [docs] draft: XE main documentation page
quick dirty :) Am Samstag, den 10.10.2009, 17:59 +0200 schrieb Roman Friesen: Hello, currently the xwiki documentation runs on several wiki instances and spaces. Unfortunately it's not structured well too, so it's really very hard to find required information. It's my experience. I think something like a Table of Content could help indeed. Probably it would be fix dirty solution, but nevertheless a solution. Please look at the current draft for that page: http://dev.xwiki.org/xwiki/bin/view/Drafts/XEDocMain Any feedback/help would be appreciated. Regards, Roman ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] [docs] Contribution Draft
Hello, I've started work on the Contribution draft: http://dev.xwiki.org/xwiki/bin/view/Drafts/XEContribute Any help/feedback would be very appreciated. Especially as my English skills are not good enough to produce high quality texts. @Vincent: I have seen your improvements, thanks :) First I sent this e-mail on Sunday, but unfortunately from a wrong e-mail... :( Thanks, Roman ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Paper Cut draft
Hi Vincent, probably I have been understanding something wrong :) I see following groups in XWiki project: 1) XWiki committers: - core developers like you 2) XWiki users: - providing patches - helping on documentation, translations etc. - other users My suggestion was to make an extra focus on small usability issues, because these remain unattended very often. The question is only, who should fix these? In my opinion, both groups: XWiki committers and users. XWiki committers as a guarantee, that at least a few of such small usability issues will be fixed at any rate. This guaranteed fixes would fill this usability project with a *real* life, attracting more user attention and in the end more users/contributors providing patches (I hope). Else we can mark hundred of issues as usability problems and wait for the first patch all the time... I think, it would be much more a promoting project, because, I suppose, in fact you fix such issues every release too. What kind of contribution would like to bring? Providing patches? Marking issues? Reporting and marking issues, documentation, promoting (for example, regularly status reports on the user mailing list). What we need is an agreement for how we tag usability issues: - with the usability keyword - with the ux keyword - with something else For me it's not really important, the main thing: - it would be easy also for jira inexperienced users, to mark reports as usability issues - we can easy filter it I think it's interesting to be able to see trivial issues independently of usability issues and vice versa. exactly! :) Regards, Roman P.S. There are always more people giving ideas, than people implementing that :D So don't hesitate to say NO, if you expect more troubles than benefits here :) Am Sonntag, den 04.10.2009, 02:34 +0200 schrieb Vincent Massol: Hi Roman, On Oct 3, 2009, at 5:14 PM, Roman Friesen wrote: Hi Vincent, Ok I've read it. I agree with it except for the workflow you propose. It's too complex and has no chance of being able to be maintained IMO. Paper Cuts should be maintained by users (approving, voting) like me, not by you. Sure but same for the difficulty field. We should all maintain it. For you it would be important (more effort) only by release planning: - reviewing the most voted paper cuts and including some of those in the future release Then I don't understand something. I thought paper cuts were about contributors doing patches. Isn't that so? If so we always try to apply all patches but some are harder to apply than others. Simple patches do get applied quickly whether paper cuts or not. I think, at the moment you do the same work, but without to know which (small) usability issues are more annoying. You will get just more feedback, but I'm not sure, if you will really happy with it, won't you? I'm fine with anything but I just don't understand what you're proposing I guess. We have a filter for patches (contributors must use the patch keyword to signify a patch and we do it when contributors forget). So that covers the use case to let committers know when to apply something. Now for contributors to know if an issue is a paper cut (ie whether it's a trivially simple issue or not) there's the difficulty field already so I see 3 cases: * the contributor has found an issue marked with a difficulty of trivial, he can submit a patch for it * the contributor is interested by an issue but the difficulty is not set. He thinks it's a paper cut and he marks it as trivial (for ex). Note that this optional and he can submit a patch without setting the difficult field * a user sees an issue he considers a good match for a paper cut and marks is with a trivial difficult in jira so that others knows about it and can see it in the jira filter list for paper cuts. What am I missing? I'd like to suggest what I've already suggested, i.e to reuse the existing trivial difficutly field instead and consider all trivial issues as paper cuts. These ideas are just different things: - I suggest to run a project for improving of usability (primarily it's good for users) I'm all for it. - you idea is to differ the difficulty of issues (primarily it's good for (new) developers) Not all easy/trivial issues are paper cuts from users point of view. And there may be small usability issues, that can be fixed only very hardly. What I was suggesting too was to tag usability issues with the usability tag if need be. Having a jira component for it is alsoan option but more limitating I think. I would like to contribute to the usability project, but without yours and other xwiki commiters agreement it wouldn't make any sense... What kind of contribution would like to bring? Providing patches? Marking issues? Trivial issues: http://jira.xwiki.org/jira/secure
[xwiki-users] Documentation Guide: cannot create macros
I wanted to create two macros for the Documentation Guide: - draftlink(url) - draftbacklink(pagename, page-url, complete-date) , see http://dev.xwiki.org/xwiki/bin/view/Community/DocGuide But I couldn't. I used the guide Writing a XWiki Rendering Macro in wiki pages: http://platform.xwiki.org/xwiki/bin/view/DevGuide/WikiMacroTutorial Steps I have performed: 1) created http://dev.xwiki.org/xwiki/bin/view/Main/MacroDraft 2) performed Edit objects 3) the problem: in the combo box Select a class there is not the class XWiki.WikiMacroClass... How can I solve this problem? Thanks, Roman ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] Paper Cut draft
Hi Vincent, please review the Paper Cut draft (beta): http://dev.xwiki.org/xwiki/bin/view/Drafts/PaperCut If you agree, please create the field Paper Cut in JIRA projects with the following values: - reported - approved - rejected Default value: None Regards, Roman Am Sonntag, den 20.09.2009, 12:56 +0200 schrieb Roman Friesen: The problem is to make a clear definition of paper cuts, so we don't have thousands of that, then it would be really a mess indeed. Sure the best would be just to fix all usability issues, but it's not a real approach. It is also important to define how these paper cuts should be handled. I would suggest the following: 1) Intention Fixing the worst usability issues that affects the most users - Paper Cuts. Together with promoting of the paper cut project it should allow to attract more xwiki users and contributors. 2) Definition (Scope) A Paper Cut is: - a _usability_ issue from the users point of view - that the _average_ user would encounter during his/her _first_ day of using xwiki - the presence of which makes the xwiki more difficult or less pleasant to use - occurring within an _existing_ piece of software (for the difficult level see below) 3) Process - a user reports a usability issue that meets the definition above and marks it as a Paper Cut in jira (the field paper cut: reported/approved/rejected) - paper cut maintainer (me? :D) checks reported paper cuts and sets the value to approved or rejected - a xwiki developer sets the difficult level of the issue (but it does not matter for the paper cut status!) - users vote in jira for reported (on its own risk ;)) and approved paper cuts - depending on the voting (severity) and the difficult level the release manager decides which paper cuts should be fixed in the next xwiki release (see remark below) The important remark to the last point: it's very important to ensure that a certain number of the worst paper cuts will be fixed in any case. Else we can discuss a lot of time about that, but without any effect. Furthermore, without seeing a real progress (live) in the paper cut project we cannot really motivate newcomers to participate in that. Therefore including of the core developer team is really essential. What about the following slogan on the PaperCut page? XWiki developers promise you to fix every release 10 worst paper cuts! Help by identifying or even fixing much more paper cuts! The number does not matter here, just replace it with a realistic one. XWiki developers could pick up more difficult issues and let fix easy/trivial issues by newcomers. Best regards, Roman Am Samstag, den 19.09.2009, 22:02 -0400 schrieb Caleb James DeLisle: As far as I can see, a paper cut meets 2 criteria: 1. It is easily repaired, devs will know this, users may not. 2. New users tend to bump into it while learning the interface. New users will know this but devs may not. Devs will be very adept at navigating the system and will be able to (without noticing) avoid issues which will cause trouble for new users. If I were naming them I would call #1 trivial issues, and #2 sharp edges. To satisfy criteria 2 an issue doesn't even need to be a bug, it could just be a UX idiosyncrasy. I have reported a few bugs which are trivial to repair, but very difficult to detect, definitely not in the first day :) Those are my thoughts. Caleb James DeLisle Vincent Massol wrote: On Sep 19, 2009, at 11:25 PM, Ecaterina Valica wrote: The original Ubuntu paper cut definition Put briefly, *a paper cut is* *a trivially fixable usability bug that the average user would encounter on his/her first day of using a brand new installation of Ubuntu Desktop Edition* so the papercut is so much trivial than it is an usability bug. How can he tag with papercut if he doesn't know if it's a trivial issue (since the definition of a paper cut is that it's a trivial issue)! :) If the developer comes and marks it difficult, we still know that the user though that the issue needed attention and raises an usability problem. I don't think papercut == usability issue. For usability issues we should tag them with usability IMO since the need is more general than just for papercuts. Thanks -Vincent IMO if we want to make this initiative an user reporting process, it's easier and more intuitive to mark the reported issues with a tag that states the paperCut concept, than to mark it with a difficulty level. But we also need to know usability issues so we need that usability tag + we already have the notion of difficulty. It's all about the amount of work to do. Proposing ideas is easy but following them up is hard to the less new concepts introduced the easiest it is. Anyway provided you tag with usability and the difficult level you
[xwiki-users] Documentation Guide
am I only a person, who thinks xwiki needs something like that? http://dev.xwiki.org/xwiki/bin/view/Drafts/XEDocContribution Regards, Roman Am Sonntag, den 27.09.2009, 12:26 +0200 schrieb Roman Friesen: Please look at http://dev.xwiki.org/xwiki/bin/view/Drafts/XEMainProposal Sometimes I linked to existing pages, sometimes to new drafts/proposal pages. These are: - How to contribute proposal: http://dev.xwiki.org/xwiki/bin/view/Drafts/XEContribute - Documentation proposal: http://dev.xwiki.org/xwiki/bin/view/Drafts/XEDocMain - Documentation Guide proposal: http://dev.xwiki.org/xwiki/bin/view/Drafts/XEDocContribution - User cookbook proposal: http://dev.xwiki.org/xwiki/bin/view/Drafts/XEDocUserCookbook Especially the Documentation Guide is very important, as it defines the way, how the documentation should be worked on. Any feedback would be very appreciated. P.S. 1) My comments are marked as quotes and/or just with italic style. 2) I would thank www.ubuntuusers.de, where I could collect really good documentation experience. Thanks, Roman Am Freitag, den 25.09.2009, 18:19 +0200 schrieb roman.frie...@ropardo.de: Hello, in my opinion, the current xwiki documentation is not optimal in many ways: - not well structured - not up-to-date - unclear where/who/how should take care about that (it's for everyone editable now, but it doesn't seem to be a really good approach...) I would suggest to separate the final documentation and writing of the documentation, for example with two spaces: 1) final docs - no comments - editable only for the doc team 2) staging (writing, reviewing etc.) - with comments - editable for all registered users Among other things (quality), in this way all users can contribute to the documentation without having fear to make mistakes. If you like, please create a staging space for the Xwiki Enterprise documentation, then I could start with a basic structure, process description etc. Best regards, Roman ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Paper Cut draft
Hi Vincent, Ok I've read it. I agree with it except for the workflow you propose. It's too complex and has no chance of being able to be maintained IMO. Paper Cuts should be maintained by users (approving, voting) like me, not by you. For you it would be important (more effort) only by release planning: - reviewing the most voted paper cuts and including some of those in the future release I think, at the moment you do the same work, but without to know which (small) usability issues are more annoying. You will get just more feedback, but I'm not sure, if you will really happy with it, won't you? I'd like to suggest what I've already suggested, i.e to reuse the existing trivial difficutly field instead and consider all trivial issues as paper cuts. These ideas are just different things: - I suggest to run a project for improving of usability (primarily it's good for users) - you idea is to differ the difficulty of issues (primarily it's good for (new) developers) Not all easy/trivial issues are paper cuts from users point of view. And there may be small usability issues, that can be fixed only very hardly. I would like to contribute to the usability project, but without yours and other xwiki commiters agreement it wouldn't make any sense... The second approach is not really interesting for me, because it's not my intention to become an xwiki developer. But it's still very good idea. Regards, Roman Am Samstag, den 03.10.2009, 13:05 +0200 schrieb Vincent Massol: Hi Roman, Thanks for working on this. On Oct 3, 2009, at 12:23 PM, Roman Friesen wrote: Hi Vincent, please review the Paper Cut draft (beta): http://dev.xwiki.org/xwiki/bin/view/Drafts/PaperCut Ok I've read it. I agree with it except for the workflow you propose. It's too complex and has no chance of being able to be maintained IMO. Even more it'll make it more difficult to maintain our current difficulty field (which we already have a very hard time maintaining - check how many trivial issues don't have it set for ex). I'd like to suggest what I've already suggested, i.e to reuse the existing trivial difficutly field instead and consider all trivial issues as paper cuts. If you agree, please create the field Paper Cut in JIRA projects with the following values: - reported - approved - rejected Default value: None This seems too procedural IMO and I still don't easy how using the difficulty field won't work. WDYT? Thanks -Vincent Regards, Roman Am Sonntag, den 20.09.2009, 12:56 +0200 schrieb Roman Friesen: The problem is to make a clear definition of paper cuts, so we don't have thousands of that, then it would be really a mess indeed. Sure the best would be just to fix all usability issues, but it's not a real approach. It is also important to define how these paper cuts should be handled. I would suggest the following: 1) Intention Fixing the worst usability issues that affects the most users - Paper Cuts. Together with promoting of the paper cut project it should allow to attract more xwiki users and contributors. 2) Definition (Scope) A Paper Cut is: - a _usability_ issue from the users point of view - that the _average_ user would encounter during his/her _first_ day of using xwiki - the presence of which makes the xwiki more difficult or less pleasant to use - occurring within an _existing_ piece of software (for the difficult level see below) 3) Process - a user reports a usability issue that meets the definition above and marks it as a Paper Cut in jira (the field paper cut: reported/approved/rejected) - paper cut maintainer (me? :D) checks reported paper cuts and sets the value to approved or rejected - a xwiki developer sets the difficult level of the issue (but it does not matter for the paper cut status!) - users vote in jira for reported (on its own risk ;)) and approved paper cuts - depending on the voting (severity) and the difficult level the release manager decides which paper cuts should be fixed in the next xwiki release (see remark below) The important remark to the last point: it's very important to ensure that a certain number of the worst paper cuts will be fixed in any case. Else we can discuss a lot of time about that, but without any effect. Furthermore, without seeing a real progress (live) in the paper cut project we cannot really motivate newcomers to participate in that. Therefore including of the core developer team is really essential. What about the following slogan on the PaperCut page? XWiki developers promise you to fix every release 10 worst paper cuts! Help by identifying or even fixing much more paper cuts! The number does not matter here, just replace it with a realistic one. XWiki developers could pick up more difficult issues and let fix
Re: [xwiki-users] Documentation Guide
This is very nice. Please merge it with the existing http://dev.xwiki.org/xwiki/bin/view/Community/Contributing page by making a children page of it and having it linked from the Contributing page. done ;) Roman Am Samstag, den 03.10.2009, 13:07 +0200 schrieb Vincent Massol: On Oct 3, 2009, at 12:26 PM, Roman Friesen wrote: am I only a person, who thinks xwiki needs something like that? http://dev.xwiki.org/xwiki/bin/view/Drafts/XEDocContribution This is very nice. Please merge it with the existing http://dev.xwiki.org/xwiki/bin/view/Community/Contributing page by making a children page of it and having it linked from the Contributing page. Thanks! -Vincent Regards, Roman Am Sonntag, den 27.09.2009, 12:26 +0200 schrieb Roman Friesen: Please look at http://dev.xwiki.org/xwiki/bin/view/Drafts/XEMainProposal Sometimes I linked to existing pages, sometimes to new drafts/ proposal pages. These are: - How to contribute proposal: http://dev.xwiki.org/xwiki/bin/view/Drafts/XEContribute - Documentation proposal: http://dev.xwiki.org/xwiki/bin/view/Drafts/XEDocMain - Documentation Guide proposal: http://dev.xwiki.org/xwiki/bin/view/Drafts/XEDocContribution - User cookbook proposal: http://dev.xwiki.org/xwiki/bin/view/Drafts/XEDocUserCookbook Especially the Documentation Guide is very important, as it defines the way, how the documentation should be worked on. Any feedback would be very appreciated. P.S. 1) My comments are marked as quotes and/or just with italic style. 2) I would thank www.ubuntuusers.de, where I could collect really good documentation experience. Thanks, Roman Am Freitag, den 25.09.2009, 18:19 +0200 schrieb roman.frie...@ropardo.de: Hello, in my opinion, the current xwiki documentation is not optimal in many ways: - not well structured - not up-to-date - unclear where/who/how should take care about that (it's for everyone editable now, but it doesn't seem to be a really good approach...) I would suggest to separate the final documentation and writing of the documentation, for example with two spaces: 1) final docs - no comments - editable only for the doc team 2) staging (writing, reviewing etc.) - with comments - editable for all registered users Among other things (quality), in this way all users can contribute to the documentation without having fear to make mistakes. If you like, please create a staging space for the Xwiki Enterprise documentation, then I could start with a basic structure, process description etc. Best regards, Roman ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] xwiki documentation relaunch
Please look at http://dev.xwiki.org/xwiki/bin/view/Drafts/XEMainProposal Sometimes I linked to existing pages, sometimes to new drafts/proposal pages. These are: - How to contribute proposal: http://dev.xwiki.org/xwiki/bin/view/Drafts/XEContribute - Documentation proposal: http://dev.xwiki.org/xwiki/bin/view/Drafts/XEDocMain - Documentation Guide proposal: http://dev.xwiki.org/xwiki/bin/view/Drafts/XEDocContribution - User cookbook proposal: http://dev.xwiki.org/xwiki/bin/view/Drafts/XEDocUserCookbook Especially the Documentation Guide is very important, as it defines the way, how the documentation should be worked on. Any feedback would be very appreciated. P.S. 1) My comments are marked as quotes and/or just with italic style. 2) I would thank www.ubuntuusers.de, where I could collect really good documentation experience. Thanks, Roman Am Freitag, den 25.09.2009, 18:19 +0200 schrieb roman.frie...@ropardo.de: Hello, in my opinion, the current xwiki documentation is not optimal in many ways: - not well structured - not up-to-date - unclear where/who/how should take care about that (it's for everyone editable now, but it doesn't seem to be a really good approach...) I would suggest to separate the final documentation and writing of the documentation, for example with two spaces: 1) final docs - no comments - editable only for the doc team 2) staging (writing, reviewing etc.) - with comments - editable for all registered users Among other things (quality), in this way all users can contribute to the documentation without having fear to make mistakes. If you like, please create a staging space for the Xwiki Enterprise documentation, then I could start with a basic structure, process description etc. Best regards, Roman ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [ANN] XWiki Enterprise and XWiki Enterprise Manager 2.0 released
I have just read the release notes... I'm really impressed... Thank you very much! Roman Am Freitag, den 25.09.2009, 18:49 +0200 schrieb Thomas Mortagne: The XWiki development team is pleased to announce the release of XWiki Enterprise and XWiki Enterprise Manager 2.0. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download More than 400 issues were fixed from XWiki Enterprise 1.9.3 to XWiki Enterprise 2.0. Many thanks to the very active community for all the reports and the contributions ! Main changes from 1.9.3: * new Colibri skin and easy color modifications * many new 2.0 macro and improvements on existing macros * new wiki based 2.0 macros * new event distribution and clustering support * many WYSIWYG improvements * many rendering improvements * many general UI improvements * new Swedish and Korean translation and updated translations for lots of other languages For more informations see the releases notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise20 and http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM20 Thanks -The XWiki dev team ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [XWIKI-4375] xwiki paper cuts
I'm not sure about the link from project health. That page was to give stats about the project health. WDYT? I think, if a project take care even about small usability issues (paper cuts), it's a _very_ good sign of the project health. Probably the current title Project Health does not meet the content of the page, what about Project Stats? Anyway feel free to remove the link from the page ;) Best regards, Roman Am Samstag, den 19.09.2009, 19:19 +0200 schrieb Vincent Massol: On Sep 19, 2009, at 7:14 PM, Roman Friesen wrote: Feel free to start a PaperCut page on dev.xwiki.org done: http://dev.xwiki.org/xwiki/bin/view/Main/PaperCut cool Currently this page is linked from the page : - XWiki Project Health: http://dev.xwiki.org/xwiki/bin/view/Community/Project+Health I'm not sure about the link from project health. That page was to give stats about the project health. WDYT? - Contributing: http://dev.xwiki.org/xwiki/bin/view/Community/Contributing Yes this is good and where I'd have put it. Thanks -Vincent P.S I will do my best, regarding as always available time. Best regards, Roman Am Samstag, den 19.09.2009, 18:28 +0200 schrieb Vincent Massol: On Sep 19, 2009, at 6:27 PM, Vincent Massol wrote: On Sep 19, 2009, at 6:22 PM, Roman Friesen wrote: Hello, I have just created the jira task XWIKI-4375: http://jira.xwiki.org/jira/browse/XWIKI-4375 description As you probably know the Ubuntu team has starter the project One Hundred Paper Cuts: https://launchpad.net/hundredpapercuts They define a paper cut as (https://wiki.ubuntu.com/PaperCut): * a bug, or an unintended problem occurring within an existing piece of software, * the presence of which makes a computer more difficult or less pleasant to use, * that is easy to fix, * that the average user would encounter during his/her first day of using XWiki is a great software but it contains also a lot of paper cuts. Such little but annoying bugs or usability issues would be a great entry point for new xwiki developers, because they are easy to fix. But also experienced xwiki commiters could relax fixing this paper cuts after their hard work ;) The proposal would be to start a similar task/project for identifying paper cuts in xwiki. Related jira issues could be just linked to this jira task. /description I have already linked one paper cut to this jira task - XWIKI-3335. Any feedback would be very appreciated. Hi Roman, (some comment I put on the jira issue but are better posted here) Great idea. We had started something similar but now you've given it a name: a Paper Cut. What we've done so far was to identify easy to fix bug and mark them as easy in jira. For example here's the current list of issues marked as trivial in XWiki core (we need to extend this notion to all jira projects right now I think it's only in core): • Trivial: http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hiderequestId=10534 We could decide that the trivial category we have corresponds to paper cuts. Feel free to start a PaperCut page on dev.xwiki.org Thanks -Vincent • Easy: http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hiderequestId=10535 Here's some work to be done IMO: • Review existing issues and verify the difficulty is correctly set • Add these custom fields to all projects in jira • Prepare a page on dev.xwiki.org to explain this Paper Cut thing • Promote it on the xwiki mailing lists, twitter, etc Thanks -Vincent PS: I'm not sure XWIKI-3335 is that trivial... :) ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [XWIKI-4375] xwiki paper cuts
Hi Marius, you have my vote. Thank you, Roman Am Sonntag, den 20.09.2009, 09:39 +0300 schrieb Marius Dumitru Florea: Hi Roman, Roman Friesen wrote: Hello, I have just created the jira task XWIKI-4375: http://jira.xwiki.org/jira/browse/XWIKI-4375 description As you probably know the Ubuntu team has starter the project One Hundred Paper Cuts: https://launchpad.net/hundredpapercuts They define a paper cut as (https://wiki.ubuntu.com/PaperCut): * a bug, or an unintended problem occurring within an existing piece of software, * the presence of which makes a computer more difficult or less pleasant to use, * that is easy to fix, * that the average user would encounter during his/her first day of using XWiki is a great software but it contains also a lot of paper cuts. Such little but annoying bugs or usability issues would be a great entry point for new xwiki developers, because they are easy to fix. But also experienced xwiki commiters could relax fixing this paper cuts after their hard work ;) The proposal would be to start a similar task/project for identifying paper cuts in xwiki. Related jira issues could be just linked to this jira task. /description I have already linked one paper cut to this jira task - XWIKI-3335. Any feedback would be very appreciated. Your initiative is good, but IMO the easiest way to promote an issue is to vote for it. Right now XWIKI-3335 has no votes (and nobody watching it, besides me who created it). Regarding XWIKI-3335, it's not hard to fix indeed but it can slow down the editing (navigating with the arrow keys precisely) because the editor will have to make a non trivial test each time you press the left/right arrow key (what's the current caret position? what's the previous/next _visible_ node relative to the current caret position? Is that node a macro container?). I can fix it but I need your vote. Thanks, Marius Best regards, Roman ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [XWIKI-4375] xwiki paper cuts
The problem is to make a clear definition of paper cuts, so we don't have thousands of that, then it would be really a mess indeed. Sure the best would be just to fix all usability issues, but it's not a real approach. It is also important to define how these paper cuts should be handled. I would suggest the following: 1) Intention Fixing the worst usability issues that affects the most users - Paper Cuts. Together with promoting of the paper cut project it should allow to attract more xwiki users and contributors. 2) Definition (Scope) A Paper Cut is: - a _usability_ issue from the users point of view - that the _average_ user would encounter during his/her _first_ day of using xwiki - the presence of which makes the xwiki more difficult or less pleasant to use - occurring within an _existing_ piece of software (for the difficult level see below) 3) Process - a user reports a usability issue that meets the definition above and marks it as a Paper Cut in jira (the field paper cut: reported/approved/rejected) - paper cut maintainer (me? :D) checks reported paper cuts and sets the value to approved or rejected - a xwiki developer sets the difficult level of the issue (but it does not matter for the paper cut status!) - users vote in jira for reported (on its own risk ;)) and approved paper cuts - depending on the voting (severity) and the difficult level the release manager decides which paper cuts should be fixed in the next xwiki release (see remark below) The important remark to the last point: it's very important to ensure that a certain number of the worst paper cuts will be fixed in any case. Else we can discuss a lot of time about that, but without any effect. Furthermore, without seeing a real progress (live) in the paper cut project we cannot really motivate newcomers to participate in that. Therefore including of the core developer team is really essential. What about the following slogan on the PaperCut page? XWiki developers promise you to fix every release 10 worst paper cuts! Help by identifying or even fixing much more paper cuts! The number does not matter here, just replace it with a realistic one. XWiki developers could pick up more difficult issues and let fix easy/trivial issues by newcomers. Best regards, Roman Am Samstag, den 19.09.2009, 22:02 -0400 schrieb Caleb James DeLisle: As far as I can see, a paper cut meets 2 criteria: 1. It is easily repaired, devs will know this, users may not. 2. New users tend to bump into it while learning the interface. New users will know this but devs may not. Devs will be very adept at navigating the system and will be able to (without noticing) avoid issues which will cause trouble for new users. If I were naming them I would call #1 trivial issues, and #2 sharp edges. To satisfy criteria 2 an issue doesn't even need to be a bug, it could just be a UX idiosyncrasy. I have reported a few bugs which are trivial to repair, but very difficult to detect, definitely not in the first day :) Those are my thoughts. Caleb James DeLisle Vincent Massol wrote: On Sep 19, 2009, at 11:25 PM, Ecaterina Valica wrote: The original Ubuntu paper cut definition Put briefly, *a paper cut is* *a trivially fixable usability bug that the average user would encounter on his/her first day of using a brand new installation of Ubuntu Desktop Edition* so the papercut is so much trivial than it is an usability bug. How can he tag with papercut if he doesn't know if it's a trivial issue (since the definition of a paper cut is that it's a trivial issue)! :) If the developer comes and marks it difficult, we still know that the user though that the issue needed attention and raises an usability problem. I don't think papercut == usability issue. For usability issues we should tag them with usability IMO since the need is more general than just for papercuts. Thanks -Vincent IMO if we want to make this initiative an user reporting process, it's easier and more intuitive to mark the reported issues with a tag that states the paperCut concept, than to mark it with a difficulty level. But we also need to know usability issues so we need that usability tag + we already have the notion of difficulty. It's all about the amount of work to do. Proposing ideas is easy but following them up is hard to the less new concepts introduced the easiest it is. Anyway provided you tag with usability and the difficult level you can also tag with whatever else you want but you should tag at least with difficulty and usability, that's my point since otherwise we'd be dropping what we've already started which is bad and not consistent and then it'll all be a mess. Thanks -Vincent ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Good News for the XWiki Open Source Project: French State Research funding
My congratulations too! Thank you very much for your current work and have a lot of fun with the further xwiki development :) Roman Am Dienstag, den 15.09.2009, 19:58 +0200 schrieb Ludovic Dubost: Hi XWiki Community, I'm happy to share some good news for the XWiki Platform and Community that we got today. We (XWiki SAS) had responded to a French Government Call for Web 2.0 Projects in early July and we got the good news today that our project was selected with 43 other projects (among 340 proposals) to receive state funding. In this project, where the research entity INRIA/ECOO and Open Source company Mandriva are also participating, we have proposed to enhance XWiki's social features and integrate Real-Time capabilities in XWiki (both for editing information and viewing information in real-time). We already worked with INRIA/ECOO on XWiki Concerto (offline and mobile XWiki) which is the specialist in France and probably Europe of Operational Transformation Technology (which is used in Google Wave for real-time capabilities). We'll talk more about the features this will bring to XWiki when we formally launch the project. We don't know yet how fast it will go to formalize the public funding and start the project (it usually takes at least a few month). It's great to be able to continue to work on innovative technologies in the Wiki space, which is not that easy as we have already so much work to package and polish all the great ideas and features that are already in the XWiki platform. It's also great to see the progress the XWiki software has made in the last year, from XWiki 1.8 to XWiki 2.0 coming out soon. The new rendering, new Wysiwyg editor, the Office Importer and now the new skin are making XWiki do a lightyear of progress in just one year ! Ludovic ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] the download link for the Latest xwiki-enterprise-wiki-2.0-rc-2.xar is wrong
the link Latest xwiki-enterprise-wiki-2.0-rc-2.xar on the download page links to the old xar xwiki-enterprise-wiki-2.0-rc-1.xar: http://forge.ow2.org/project/download.php?group_id=170file_id=13445 Best regards, Roman Am Freitag, den 18.09.2009, 19:52 +0200 schrieb Thomas Mortagne: The XWiki development team is pleased to announce the release of XWiki Enterprise 2.0 Release Candidate 2. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This is the last release candidate before the XWiki enterprise 2.0 final version 69 Jira issues has been closed for this release. Changes from 2.0 Release Candidate 1: * New Colibri skin improvements * General UI improvements * WYSIWYG improvements * Rendering 2.0 improvements * New regexp velocity tool * Update translations: de, fr, gl, ru, sk, lv, pl, sv, zh, ro, ua, ko, hi, cs As usual we need the community to heavily test this release before the final release to catch all the remaining issues. For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise20RC2 Thanks -The XWiki dev team ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] [XWIKI-4375] xwiki paper cuts
Hello, I have just created the jira task XWIKI-4375: http://jira.xwiki.org/jira/browse/XWIKI-4375 description As you probably know the Ubuntu team has starter the project One Hundred Paper Cuts: https://launchpad.net/hundredpapercuts They define a paper cut as (https://wiki.ubuntu.com/PaperCut): * a bug, or an unintended problem occurring within an existing piece of software, * the presence of which makes a computer more difficult or less pleasant to use, * that is easy to fix, * that the average user would encounter during his/her first day of using XWiki is a great software but it contains also a lot of paper cuts. Such little but annoying bugs or usability issues would be a great entry point for new xwiki developers, because they are easy to fix. But also experienced xwiki commiters could relax fixing this paper cuts after their hard work ;) The proposal would be to start a similar task/project for identifying paper cuts in xwiki. Related jira issues could be just linked to this jira task. /description I have already linked one paper cut to this jira task - XWIKI-3335. Any feedback would be very appreciated. Best regards, Roman ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [XWIKI-4375] xwiki paper cuts
Feel free to start a PaperCut page on dev.xwiki.org done: http://dev.xwiki.org/xwiki/bin/view/Main/PaperCut Currently this page is linked from the page : - XWiki Project Health: http://dev.xwiki.org/xwiki/bin/view/Community/Project+Health - Contributing: http://dev.xwiki.org/xwiki/bin/view/Community/Contributing P.S I will do my best, regarding as always available time. Best regards, Roman Am Samstag, den 19.09.2009, 18:28 +0200 schrieb Vincent Massol: On Sep 19, 2009, at 6:27 PM, Vincent Massol wrote: On Sep 19, 2009, at 6:22 PM, Roman Friesen wrote: Hello, I have just created the jira task XWIKI-4375: http://jira.xwiki.org/jira/browse/XWIKI-4375 description As you probably know the Ubuntu team has starter the project One Hundred Paper Cuts: https://launchpad.net/hundredpapercuts They define a paper cut as (https://wiki.ubuntu.com/PaperCut): * a bug, or an unintended problem occurring within an existing piece of software, * the presence of which makes a computer more difficult or less pleasant to use, * that is easy to fix, * that the average user would encounter during his/her first day of using XWiki is a great software but it contains also a lot of paper cuts. Such little but annoying bugs or usability issues would be a great entry point for new xwiki developers, because they are easy to fix. But also experienced xwiki commiters could relax fixing this paper cuts after their hard work ;) The proposal would be to start a similar task/project for identifying paper cuts in xwiki. Related jira issues could be just linked to this jira task. /description I have already linked one paper cut to this jira task - XWIKI-3335. Any feedback would be very appreciated. Hi Roman, (some comment I put on the jira issue but are better posted here) Great idea. We had started something similar but now you've given it a name: a Paper Cut. What we've done so far was to identify easy to fix bug and mark them as easy in jira. For example here's the current list of issues marked as trivial in XWiki core (we need to extend this notion to all jira projects right now I think it's only in core): • Trivial: http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hiderequestId=10534 We could decide that the trivial category we have corresponds to paper cuts. Feel free to start a PaperCut page on dev.xwiki.org Thanks -Vincent • Easy: http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hiderequestId=10535 Here's some work to be done IMO: • Review existing issues and verify the difficulty is correctly set • Add these custom fields to all projects in jira • Prepare a page on dev.xwiki.org to explain this Paper Cut thing • Promote it on the xwiki mailing lists, twitter, etc Thanks -Vincent PS: I'm not sure XWIKI-3335 is that trivial... :) ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [myxwiki] new wiki request
Many thanks! :) Am Mittwoch, den 09.09.2009, 21:26 +0200 schrieb Vincent Massol: Hi Roman, On Sep 9, 2009, at 9:11 PM, Roman Friesen wrote: Hi Vincent, thank you very much for you suggestion, I have tried it, but I'm afraid the sandbox would be not enough for me. I want test the whole xwiki engine incl. user/permission administation, skins, multilanguage etc. etc... Furthermore if the first test passes, I will use it as test/prototype platform for my future xwiki platform, where I will prepare spaces/ page structure, texts, layout etc. The wiki content will be about a doctor famous in Russia. Your wiki has been created at http://booksth.myxwiki.org/ Enjoy -Vincent Thank you, Roman Am Dienstag, den 08.09.2009, 21:17 +0200 schrieb Vincent Massol: Hi Roman, What about using the existing sandbox wiki to try it stuff out instead? We have 2 sandboxes: - one on the version used on xwiki.org: http://playground.xwiki.org/xwiki/bin/view/Main/ - one on the version used on myxwiki.org (2.0M4 right now): http://playground.myxwiki.org/xwiki/bin/view/Main/ The xwiki.org sandbox is reset every day to keep it clean while we're not yet doing this with the myxwiki.org one (but we should). Thanks -Vincent PS: We don't normally create wikis on myxwiki.org just to try stuff out. On Sep 8, 2009, at 9:05 PM, Roman Friesen wrote: oops, the server name is booksth. Am Dienstag, den 08.09.2009, 21:02 +0200 schrieb Roman Friesen: Hello, I would like to test xwiki whether it meets requirements for my future wiki. There will be only a few texts and attachments. My user is krokosjablik. Thank you, Roman ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [myxwiki] new wiki request
Hi Vincent, thank you very much for you suggestion, I have tried it, but I'm afraid the sandbox would be not enough for me. I want test the whole xwiki engine incl. user/permission administation, skins, multilanguage etc. etc... Furthermore if the first test passes, I will use it as test/prototype platform for my future xwiki platform, where I will prepare spaces/page structure, texts, layout etc. The wiki content will be about a doctor famous in Russia. Thank you, Roman Am Dienstag, den 08.09.2009, 21:17 +0200 schrieb Vincent Massol: Hi Roman, What about using the existing sandbox wiki to try it stuff out instead? We have 2 sandboxes: - one on the version used on xwiki.org: http://playground.xwiki.org/xwiki/bin/view/Main/ - one on the version used on myxwiki.org (2.0M4 right now): http://playground.myxwiki.org/xwiki/bin/view/Main/ The xwiki.org sandbox is reset every day to keep it clean while we're not yet doing this with the myxwiki.org one (but we should). Thanks -Vincent PS: We don't normally create wikis on myxwiki.org just to try stuff out. On Sep 8, 2009, at 9:05 PM, Roman Friesen wrote: oops, the server name is booksth. Am Dienstag, den 08.09.2009, 21:02 +0200 schrieb Roman Friesen: Hello, I would like to test xwiki whether it meets requirements for my future wiki. There will be only a few texts and attachments. My user is krokosjablik. Thank you, Roman ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] [myxwiki] new wiki request
Hello, I would like to test xwiki whether it meets requirements for my future wiki. There will be only a few texts and attachments. My user is krokosjablik. Thank you, Roman ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [myxwiki] new wiki request
oops, the server name is booksth. Am Dienstag, den 08.09.2009, 21:02 +0200 schrieb Roman Friesen: Hello, I would like to test xwiki whether it meets requirements for my future wiki. There will be only a few texts and attachments. My user is krokosjablik. Thank you, Roman ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
