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. > 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. > >> 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. >> > >> 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. > >> 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. 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. > -- Joachim Dreimann | *User Experience Manager* WANdisco // *Non-Stop Data* e. [email protected] twitter @jdreimann <https://twitter.com/jdreimann>
