Hi Gary, >> Personally I wouldn't have a problem with syntax that a user has to use in order to explicitly state the >> intention for such a TODO list to be converted into tickets. The issue of the discoverability of the >> functionality is one we could do with solving more generally but people will tend to know if they are creating >> a list of things that they want to be tickets.
In trac there is a plugin which implements a feature very similar to our feature. And they use some standard syntax [1]. So if you agree, we can start discussing about a standard syntax, and may be we'll be able to reuse some what of their code. >> Yes, I was thinking of something similar... I think it needs some thought though. I have uploaded an modified version of design mockup. Take a look at it [2]. This is just a simple design, and this simple macro can be modified in many ways, for an example we can use a dropdown instead of a text field at "Priority" column. And obviously it needs some more thought. So I would be more than glad to have your valuable feedbacks. >> Yes, this is fine. Wiki editing is a separate permission so people could collaborate in creation of the list. >> Possibly better though might be to add a TICKET_BATCH_CREATE permission. There is already a permission >> associated with simultaneous editing of multiple tickets and, as I mention above, this is effectively the >> creation analogue of that. Alright then, we'll create a separate permission for this feature :) >> It should be noted that this discussion is very suggestive (at least to me) of another approach involving a >> batch create page that the wiki list could pass on the work of actually creating the tickets to. I am not >> sure that this could be considered in scope of this project but it might be a longer term aim. I'm not really clear about what you tried to convey here. But as I understood this is a kind of extension of our original project. So after completing this project I'm more than happy to work on it. So can please clarify your idea a bit :) [1] https://trac-hacks.org/wiki/WikiCreateTicketPlugin#Example [2] https://issues.apache.org/bloodhound/attachment/ticket/231/design_mockup_v2.png On Fri, Mar 7, 2014 at 11:36 PM, Gary Martin <[email protected]>wrote: > On 07/03/14 16:29, Joachim Dreimann wrote: > >> On 6 March 2014 15:42, Dammina Sahabandu <[email protected]> wrote: >> >> Hi Gary, >>> First of all thank you very much for the quick reply. >>> >>> Hi Dammina, >>>> I'll go through this in more detail later but I notice that the >>>> attachments that your refer to are not available. >>>> >>> I know you got a really busy schedule. And of cause I'm not in a hurry. >>> So >>> no worries, please take any amount of time to reply :) (And I'm really >>> sorry if I'm disturbing you with these minor issues). However, I did >>> attach >>> that mockup snap into the location that you suggested. You can find it at >>> [1]. >>> >>> [1] https://issues.apache.org/bloodhound/attachment/ticket/ >>> 231/mockup.png >>> >>> Thanks >>> Dammina >>> >>> >>> On Thu, Mar 6, 2014 at 5:20 PM, Gary Martin <[email protected] >>> >>>> wrote: >>>> Hi Dammina, >>>> >>>> I'll go through this in more detail later but I notice that the >>>> attachments that your refer to are not available. I suspect our list >>>> just >>>> doesn't allow them to be added. That leaves a question of the best place >>>> >>> to >>> >>>> put them. Attaching them to https://issues.apache.org/ >>>> bloodhound/ticket/231 might be appropriate for now I suppose. >>>> >>>> Cheers, >>>> Gary >>>> >>>> >>>> >>>> On 06/03/14 11:38, Dammina Sahabandu wrote: >>>> >>>> Hi Gary, >>>>> >>>>> Thank you very much for the quick detailed feedback. It really helps me >>>>> and motivates me a lot. Here I have briefly described few design >>>>> >>>> decisions >>> >>>> on how to solve the issues that we have discovered already. >>>>> >>>>> Regarding List tracking in a wiki page: >>>>> A regex pattern matching search for '*' , '1.' etc. markups in the >>>>> complete content on the wiki page will be able to find all the numbered >>>>> lists and bullet pointed lists. But still I have to face the problem of >>>>> Intrusiveness. So I'm thinking of several ways to solve this issue. May >>>>> >>>> be >>> >>>> setting up a hidden comment(It should be some universal identifier. For >>>>> >>>> an >>> >>>> example >>>>> {{{#!comment >>>>> TicketList >>>>> }}} >>>>> ) in the wikitext to identify only the relevant lists will be a good >>>>> solution. I guess it won't be a considerable overhead for the user. Or >>>>> >>>> may >>> >>>> be we can just implement an AJAX script for the buttons visibility. >>>>> >>>> That is >>> >>>> the 'Create Tickets' button for a particular list will only be visible >>>>> >>>> for >>> >>>> the user when he is pointing the mouse pointer over that particular >>>>> >>>> list. >>> >>>> So by that way the user will only see one button at a time (Hope it >>>>> >>>> won't >>> >>>> be a big headache ;) ). So what is your opinion, will something like >>>>> >>>> this >>> >>>> work? >>>>> >>>> Yes, this should even be possible using plain CSS. If you position the >> button absolutely within the <ul> element to the top right for example, >> you >> can then set it to display: block; on ul:hover, display: none; otherwise. >> >> I'm happy to help you with these sorts of things when you get to the >> implementation stage. >> > > Personally I wouldn't have a problem with syntax that a user has to use in > order to explicitly state the intention for such a TODO list to be > converted into tickets. The issue of the discoverability of the > functionality is one we could do with solving more generally but people > will tend to know if they are creating a list of things that they want to > be tickets. > > > Anyway I will do some more thinking and try to figure out a better >>> >>>> alternative. >>>>> >>>>> Missing details in auto created ticket: >>>>> As you have mentioned, for this issue there are lots of solutions >>>>> available. Currently I'm thinking of the following solution, and I have >>>>> attached few mockups to describe the it. >>>>> 1. [mockup01] displays the initial view of the wiki when mouse pointer >>>>> >>>> is >>> >>>> not over a relevant list. >>>>> 2. When mouse pointer is over a relevant list, the button 'Create >>>>> Tickets' will be visible. [mockup02] >>>>> 3. After the user clicks on the button the creating process will run >>>>> and >>>>> display the links to appropriate tickets. And when the user pointed the >>>>> mouse over a certain ticket a button to update details of that ticket >>>>> >>>> will >>> >>>> appear.[mockup03] >>>>> >>>> The bit about update details for a ticket seems inconsistent with how >> users >> can normally interact with ticket links they encounter elsewhere. I think >> it's ok if the user just clicks the link to go to the ticket page, with no >> extra button appearing here. >> > > Yes, Joe is absolutely right there. The ticket id and summary should just > be enough to link direct to each ticket. > > > 4. Then if the user click on the button, there are two thing we can do. >>>>> i. Simply redirects the user to update ticket details pages. >>>>> >>>> [mockup06] >>> >>>> ii. Or generate a button list of required fields [mockup04] . (Assume >>>>> the state of the ticket will be 'new' and the reporter should be the >>>>> >>>> user >>> >>>> who add these list of tickets) >>>>> >>>> I think we can set sensible defaults for all required fields. >> >> >> >> 5. If we choose the process (4. ii.), then the user can add details >>> in >>> to >>> >>>> the fields one by one. [mockup05] >>>>> >>>> To edit multiple tickets, we should provide a link to an appropriately >> scoped custom query that shows the tickets just created. We should try to >> avoid introducing a separate way to do the same thing. >> > > Yes, going to the query page gives the ability to make use of the normal > batch modify process. > > > >> Hopefully all these user side changes can be achieved by few AJAX >>>>> >>>> scripts. >>> >>>> Another easier way to solve this is to define a standard way to write >>>>> these ticket lists in wiki pages. So we just have to process the list >>>>> >>>> and >>> >>>> extract the data appropriately. (Please let me know if this seams >>>>> interesting to you. Then we can discuss this in detail.) >>>>> >>>> One way to do this would be to let users create a 'ticket table' with a >> simple macro: each row would be a new ticket, each column one required >> field. Once they are filled in and the user clicks save on the wiki page, >> all rows would be converted into tickets. >> > > Yes, I was thinking of something similar... I think it needs some thought > though. > > > >> Another thing is I'm not really clear about the idea of handling >>>>> permission to add tickets using this feature. I mean as you suggested >>>>> >>>> in an >>> >>>> earlier message we need to think about, to whom we should provide >>>>> permission to use this functionality. Initially, I was thinking that >>>>> whoever has the permission to add tickets in the usual way should be >>>>> >>>> able >>> >>>> to use this functionality. But I'm not really sure about that. So there >>>>> >>>> I >>> >>>> need a little help from you to make it clear. >>>>> >>>> Yes, your suggestion seems sensible. >> > > Yes, this is fine. Wiki editing is a separate permission so people could > collaborate in creation of the list. Possibly better though might be to add > a TICKET_BATCH_CREATE permission. There is already a permission associated > with simultaneous editing of multiple tickets and, as I mention above, this > is effectively the creation analogue of that. > > It should be noted that this discussion is very suggestive (at least to > me) of another approach involving a batch create page that the wiki list > could pass on the work of actually creating the tickets to. I am not sure > that this could be considered in scope of this project but it might be a > longer term aim. > > Hope I am not confusing things here! > > Cheers, > Gary > > > >> Cheers, >> Joe >> >> >> >> >>> So what are your opinions on my suggestions. Obviously these designs >>>>> >>>> need >>> >>>> to improve a lot and for that the feedback from the community is really >>>>> important. >>>>> >>>>> Another thing is at the moment I'm trying to come up with some more >>>>> suggestions on expanding the functionality of this feature. So if you >>>>> >>>> have >>> >>>> anything in your mind please let me know :) >>>>> >>>>> Thanks >>>>> Dammina >>>>> >>>>> >>>>> On Tue, Mar 4, 2014 at 10:46 PM, Gary Martin <[email protected] >>>>> >>>> <mailto: >>> >>>> [email protected]>> wrote: >>>>> >>>>> Hi Dammina, >>>>> >>>>> Firstly I should point out that this project would ultimately be >>>>> defined by you and so it is of particular importance that you make >>>>> this both challenging enough and realistic enough for you to >>>>> achieve in the available time. >>>>> >>>>> You have spotted a very interesting issue that you might want to >>>>> solve as part of this project and if I were you I would certainly >>>>> use this to strengthen your application. The ability for users to >>>>> specify details like ticket type, milestone, components and other >>>>> fields certainly seems very desirable to me but there are going to >>>>> be various solutions to the problem which will vary in complexity >>>>> of implementation and actual usability. >>>>> >>>>> If you come up with some suggestions, we could discuss what the >>>>> community would prefer (and there is a good chance that we will >>>>> make more suggestions if we can) but remember to continue to >>>>> balance our advice with what you think is achievable. You may of >>>>> course need our help to understand what may be easy or difficult. >>>>> >>>>> Anyway, it is great to see that you are spotting issues that might >>>>> be solved. >>>>> >>>>> Another area you might want to give a little consideration to is >>>>> whether there might be anything you could take advantage of from >>>>> the context that the list is found in. In case you have not noted, >>>>> wiki syntax is available in a number of places including wiki >>>>> pages, ticket descriptions and comments. >>>>> >>>>> I hope that answered your question well enough! >>>>> >>>>> Cheers, >>>>> Gary >>>>> >>>>> >>>>> On 04/03/14 12:02, Dammina Sahabandu wrote: >>>>> >>>>> Hi Gary, >>>>> Another thing that I wanted to clarify is, by this method we >>>>> will only be >>>>> able to add summaries for the created tickets. May be it will >>>>> be possible >>>>> to fetch the reporter information too. But there are many more >>>>> important >>>>> fields in a ticket that should be filled such as type and >>>>> priority. So do >>>>> we need to address this issue? >>>>> >>>>> Thanks, >>>>> Dammina >>>>> >>>>> >>>>> On Tue, Mar 4, 2014 at 4:03 PM, Gary Martin >>>>> <[email protected] <mailto:[email protected] >>>>> >>>>>> wrote: >>>>>>> >>>>>> >>>>> On 04/03/14 04:32, Dammina Sahabandu wrote: >>>>> >>>>> Hi All, >>>>> >>>>> I'm Dammina Sahabandu, a 3rd year Computer Engineering >>>>> Undergraduate at >>>>> University of Moratuwa, Sri Lanka. Currently I'm doing >>>>> an internship at >>>>> WSO2 inc which is an open source middleware >>>>> organization. So I do have >>>>> experience in several Apache projects (Axis2, Synapse >>>>> etc.). So as the >>>>> first step I did some background research about the >>>>> Apache Bloodhound >>>>> project. And also I did checkout the svn repo and >>>>> installed >>>>> it successfully. >>>>> After going through the JIRA list I found several >>>>> interesting ideas, but >>>>> I'm particularly interested in the idea of creating >>>>> tickets using a >>>>> wiki list [1]. So as I understood simply the idea is >>>>> to provide a button >>>>> when there is a list in the wiki(numbered or bullet >>>>> pointed). And we need >>>>> to implement a system to create tickets using the list >>>>> after the user >>>>> clicking on that button. Then we need to update the >>>>> wiki page(the >>>>> >>>>> relevant >>>>> >>>>> list) replacing the list with the links to the created >>>>> tickets. >>>>> Is that correct? Can you please give me a feedback to >>>>> clear up the idea. >>>>> And it would be really great if you can provide some >>>>> more details about >>>>> >>>>> the >>>>> >>>>> project. >>>>> >>>>> [1] >>>>> >>>>> https://issues.apache.org/jira/browse/COMDEV-110?filter= >>> >>>> 12326260 >>>>> >>>>> Thanks >>>>> Dammina >>>>> >>>>> Hi Dammina, >>>>> >>>>> Great to hear from you. For quick reference here, the >>>>> associated ticket >>>>> for bloodhound is >>>>> https://issues.apache.org/bloodhound/ticket/231 >>>>> >>>>> I believe your interpretation of the ticket is reasonable. >>>>> What has been >>>>> stated so far is probably not a full specification for the >>>>> problem so it >>>>> would be worth considering: >>>>> >>>>> * Permissions - who is appropriate for the button to be >>>>> presented to >>>>> and who can use the button? >>>>> * Intrusiveness - not all lists will need to be turned >>>>> into tickets so >>>>> could there be means to determine this? >>>>> >>>>> That is a shorter list than I thought I would come out >>>>> with but feel >>>>> free to add to this, Dammina. As this would be your >>>>> project, it might be >>>>> better if you try to answer those questions rather than >>>>> getting us to >>>>> prescribe answers. This may be useful for strengthening >>>>> your final >>>>> project proposal too. >>>>> >>>>> Cheers, >>>>> Gary >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Dammina Sahabandu. >>>>> Undergraduate Department of Computer Science and Engineering >>>>> University of Moratuwa >>>>> Sri Lanka. >>>>> >>>>> >>>> >>> -- >>> Dammina Sahabandu. >>> Undergraduate Department of Computer Science and Engineering >>> University of Moratuwa >>> Sri Lanka. >>> >>> >> >> > -- Dammina Sahabandu. Undergraduate Department of Computer Science and Engineering University of Moratuwa Sri Lanka.
