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.
