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]>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]>
>> 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.
