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? 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] >> 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) >> 5. If we choose the process (4. ii.), then the user can add details in to >> the fields one by one. [mockup05] >> >> 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.) >> >> 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. >> >> 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.
