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:
Re: [xwiki-users] Paper Cut draft
Hi guys, I think the papercut idea is good too. Roughly defined, papercuts are UX issues reported by users that are trivial to fix for developers. I think the best way to translate that into XWiki's JIRA is to use the UX keyword and to create a Paper Cut filter that lists all issues that have their difficulty field set to trivial and the UX keyword. I think this solution would be ok for both of you :-) On Sun, Oct 4, 2009 at 1:30 PM, Roman Friesen xw...@frolo.de wrote: 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'm +1 for the UX keyword. I think it's easy enough for users to apply it to an existing issue. Guillaume 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)
[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
Re: [xwiki-users] how to mask those elements
Hello! I want to hide some elements of wiki users (but accessible for administrator) : - The history tab, information and attachments to pages. Only tab comment must be accessible. See http://bit.ly/3c8O3f It work fine, but i must insert the code in each page... And administrator can't acces the hidden tabs : is there a way to automate for all page, and for all user except the administrators (or users with edit rights) ? - The recent changes to the main.dashboard (or then simplify to see only the records created and updated without avatars or attachments). Just edit the page and change it. i succeed to delete the avatar, but not the attachments. - Spaces shelduler, stat, xwiki and panel These spaces are already hidden for simple users. Indeed !Thanks again ! Thanks -Vincent ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users _ Messenger débarque dans Hotmail ! Essayez-le ! http://www.windowslive.fr/hotmail/web-messenger/ ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
