Trac replacement research

[Jean-Paul Calderone]

On Fri, Aug 16, 2019 at 11:54 AM meejah <meejah at meejah.ca> wrote:

> Jessie France <jessielisbetfrance at gmail.com> writes:
>
> > We are looking into replacing trac but before we do, I need to
> > identify all the various ways people are using it for TahoeLAFS. What
> > features are you using in trac?
>
> The Wiki and ticketing-system are the most important. Any new system
> must start out with the content from the Trac wiki and all the Trac
> tickets migrated over.
>
>
For the ticketing system, there are a few really useful features that it
would be nice to preserve:

   - The ability to group related tickets to track progress against a
   specific goal.  Trac has milestones as well as labels that can be queried
   against.  Something that fits this use-case is fairly important.  I think
   there are over a thousand open tickets in Trac.  That's enough tickets that
   it's really hard to make sense of what's going on.  If you can narrow that
   down to 10-20 tickets aimed at one purpose, it becomes manageable.
   - The ability to integrate with the code hosting system.  Currently,
   GitHub PRs can automatically close Trac tickets when they are merged.  This
   has some rough spots (you have to get the message just right and in just
   the right place) and there's room for improvement.  I wouldn't want to lose
   this, though, since leaving already-finished tickets open just reduces the
   value of the ticket system.

For the wiki, we certainly want to preserve the content but I wonder how
integrated it needs to be with the rest of the system.  Are there wiki
features that relate to tickets or code hosting that benefit from tight
integration?  Or could the project deploy a separate wiki hosting system
that's independent of the issue tracker and other components?  Either way,
I agree that migrating content is a requirement.

Another area that is pretty important is the account management / spam
prevention system.  A significant motivator to get off Trac is that we have
no solution to the spam problem.  It's tempting to reach for a system that
supports a curated list of OAuth providers (eg GitHub, Google) as these
often seem to have minimal spam problems.  However, this might be
unacceptable to some of Tahoe-LAFS' users and maintainers.  An alternative
might be a system with moderated registration (which Trac supposedly has
but I have failed to set it up).  There may be other spam-prevention
measures out there which work equally well (but I have failed to configure
Trac's Spambayes-based filtering in a way that's at all useful).

Thanks!
Jean-Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20190820/665de97d/attachment.html>