Hi everyone,
as some of you might already know we have been working on a survey to see if we can identify possible Trac alternatives. The original question was: should we continue to patch Trac until we love it, or should we look around for a tool that might be able to do what we need?
The idea of the survey is to identify what we actually need from a ticketing/wiki tool and eventually identify a solution that has all that we want (or that we can work with).
So please take your time to answer the survey (it doesn't take longer than 2/3 minutes) https://storm.torproject.org/shared/mgNGJd30HpN8IL5XvoC4QhloRgDGLcpr6VzR89by...
For any questions/doubts/rants feel free to write or ping me.
-silvia
On 3 Mar 2017, at 04:37, Silvia [Hiro] hiro@torproject.org wrote:
Hi everyone,
as some of you might already know we have been working on a survey to see if we can identify possible Trac alternatives. The original question was: should we continue to patch Trac until we love it, or should we look around for a tool that might be able to do what we need?
The idea of the survey is to identify what we actually need from a ticketing/wiki tool and eventually identify a solution that has all that we want (or that we can work with).
So please take your time to answer the survey (it doesn't take longer than 2/3 minutes) https://storm.torproject.org/shared/mgNGJd30HpN8IL5XvoC4QhloRgDGLcpr6VzR89by...
For any questions/doubts/rants feel free to write or ping me.
This isn't my area of expertise, but I have no idea what these mean:
Project management functionalities Projects flow
Also, what's the difference between: Handle tickets Issues
The survey seems to be written with the idea that the trac replacement will be one system that will do everything we can possibly think of.
But I'm in favour of having separate systems that do the tasks you listed: that's more maintainable, easier to scale, fewer single points of failure, and easier to replace just one if it turns out to be bad in future. (Oh, and more secure, too.)
Unless, of course, there are compelling reasons for tight integration.
For example, maybe it's a good idea to have a system that does code review and tickets. But I'm yet to be convinced it should do the wiki as well, and it really doesn't need to send encrypted emails.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
On 03/03/17 00:21, teor wrote:
This isn't my area of expertise, but I have no idea what these mean:
Project management functionalities Projects flow
Also, what's the difference between: Handle tickets Issues
Hi Teor,
The survey is a bit redundant because we are trying to understand how people work around here. If you do not use project management canvas, you simply do not need them. Some systems though offer that functionality, so that's why it is included in the survey.
This idea also affects the tickets/issue redundancy point. If you are used to work on code reviews you think of issues/bugs, but otherwise some people might think to report a ticket as a general problem (with various other fields inside) that isn't generally linked to a code repository or project.
The survey seems to be written with the idea that the trac replacement will be one system that will do everything we can possibly think of.
But I'm in favour of having separate systems that do the tasks you listed: that's more maintainable, easier to scale, fewer single points of failure, and easier to replace just one if it turns out to be bad in future. (Oh, and more secure, too.)
Unless, of course, there are compelling reasons for tight integration.
For example, maybe it's a good idea to have a system that does code review and tickets. But I'm yet to be convinced it should do the wiki as well, and it really doesn't need to send encrypted emails.
Again various systems (see gitlab for example) also have a project wiki with each repository. So that's why it is mentioned.
Regarding encrypted emails: the system doesn't need to send encrypted emails, but maybe we need that feature for private issue reporting. This mean we will need to hook it up with Schleuder for example. So it helps to know we need that too when evaluating a different system.
Let me stress again that the whole point of the survey is understanding how we work. So for people having the possibility to handle issues w/ code review really helps, some other team might have a specific flow they like to work with. I, for example, understand why some do not like to have to use patches (or link to branches) to comment on pull request, but others are fine with it.
I hope this clarifies.
-silvia
Silvia [Hiro] transcribed 1.2K bytes:
Hi everyone,
as some of you might already know we have been working on a survey to see if we can identify possible Trac alternatives. The original question was: should we continue to patch Trac until we love it, or should we look around for a tool that might be able to do what we need?
The idea of the survey is to identify what we actually need from a ticketing/wiki tool and eventually identify a solution that has all that we want (or that we can work with).
So please take your time to answer the survey (it doesn't take longer than 2/3 minutes) https://storm.torproject.org/shared/mgNGJd30HpN8IL5XvoC4QhloRgDGLcpr6VzR89by...
For any questions/doubts/rants feel free to write or ping me.
-silvia
Hi silvia!
Thanks for this! I took the survey a while ago, so I didn't want to risk messing up the results by taking it again to give a suggestion.
One neat thing that I've seen some trackers have (e.g. Gitlab, Github, others) is the ability to add a "reaction" to a specific comment on a ticket, or to the ticket description. I don't know if full-on emoji reactions are really necessary, but it would be a neat extra feature to at least be able to +1 someone's comments, like to praise them for figuring out why a certain bug was happening.
I only thought of it because this Twitter like/RT bug has been annoying me, and Arthur and Jens figured out what was up with the POST requests not being authenticated: https://bugs.torproject.org/21555#comment:12 I went to click the +♥ button, but then remembered I was on Trac not Github.
Anyway, it's not a necessary thing, I just thought it would be a nice thing to be able to give people a thumbs up when they do a good job. :)
Best,
On Thu, 02 Mar 2017, Silvia [Hiro] wrote:
The idea of the survey is to identify what we actually need from a ticketing/wiki tool and eventually identify a solution that has all that we want (or that we can work with).
I forgot to put that on the original survey answer, but something I use extensively is this:
o Define my own, personal queries and reports, and have all their results show up on a (personal) page that I look at. https://trac.torproject.org/projects/tor/wiki/user/weasel
Also, it'd be nice to have a ticket/issue state that does what RT's stalled does. /Stalled/ is a state that a ticket can be in, and any future action (in particular a reply) by any person moves it back into its previous state (or maybe just Open).
In most bug overviews one would hide stalled tickets. The idea being that things that aren't actionable until you get some more input from the user should be set to stalled when you request that info. Until you then get that info, there's no point in having the ticket clutter up your overview. (We might also be able to get that with trac, if we configure the workflow just right.)
Cheers,
Hi,
On Wed, Mar 08, 2017 at 10:37:53AM +0000, Peter Palfrader wrote:
o Define my own, personal queries and reports, and have all their results show up on a (personal) page that I look at. https://trac.torproject.org/projects/tor/wiki/user/weasel
+1
I've been doing this so far with bookmarks per report, but this looks like exactly what I want. I use bugwarrior to collect all my tickets that I need to action into taskwarrior, but sometimes there are other tickets that I should at least look at and being able to find those easily makes it more likely that I will look at them.
If we have the GitHub approach of splitting up issues across sub-projects and making it more difficult for tickets to interact with each other (e.g. on Trac an Onionoo ticket can be a child ticket of an Atlas ticket) then I'm going to be less likely to look at related tickets that might be important.
Thanks, Iain.
On Wed, Mar 8, 2017 at 5:37 AM, Peter Palfrader weasel@torproject.org wrote:
On Thu, 02 Mar 2017, Silvia [Hiro] wrote:
The idea of the survey is to identify what we actually need from a ticketing/wiki tool and eventually identify a solution that has all that we want (or that we can work with).
I forgot to put that on the original survey answer, but something I use extensively is this:
o Define my own, personal queries and reports, and have all their results show up on a (personal) page that I look at. https://trac.torproject.org/projects/tor/wiki/user/weasel
Also, it'd be nice to have a ticket/issue state that does what RT's stalled does. /Stalled/ is a state that a ticket can be in, and any future action (in particular a reply) by any person moves it back into its previous state (or maybe just Open).
In most bug overviews one would hide stalled tickets. The idea being that things that aren't actionable until you get some more input from the user should be set to stalled when you request that info. Until you then get that info, there's no point in having the ticket clutter up your overview. (We might also be able to get that with trac, if we configure the workflow just right.)
+1 on both of these ideas.
And here is, I think, a must-have for me: It needs to be possible to make a URL that corresponds to a query. I don't know of any bugtrackers that _don't_ allow that, but it sure would be sad if I couldn't paste a link to a query for (eg) "All tickets in milestone X in state needs_review".
On 2 March 2017 at 18:37, Silvia [Hiro] hiro@torproject.org wrote:
The idea of the survey is to identify what we actually need from a ticketing/wiki tool and eventually identify a solution that has all that we want (or that we can work with).
Hello Silvia.
Thank you for doing this work!
One feature that I've noticed I'm missing while working with Tor is the ability to have patches run on various buildbot/CI systems before I request review from another developer. While we do not have a unified review tool right now, I'd like this to be considered for such a tool if possible :-)
This allows me to verify that my changes doesn't break compilation and our `make check` test-suites on platforms that I might not have easily available to me in my daily work. Additionally it ensures that I don't waste other people's time asking them to review stuff that might need multiple fix-up commits after the patches land in the repository to keep our tree green :-)
Cheers, Alex.
tor-project@lists.torproject.org
-
Alexander Færøy -
Iain R. Learmonth -
isis agora lovecruft -
Nick Mathewson -
Peter Palfrader -
Silvia [Hiro] -
teor