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.
