<div dir="ltr"><div dir="ltr">On Fri, Aug 16, 2019 at 11:54 AM meejah <<a href="mailto:meejah@meejah.ca">meejah@meejah.ca</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Jessie France <<a href="mailto:jessielisbetfrance@gmail.com" target="_blank">jessielisbetfrance@gmail.com</a>> writes:<br>
<br>
> We are looking into replacing trac but before we do, I need to<br>
> identify all the various ways people are using it for TahoeLAFS. What<br>
> features are you using in trac?<br>
<br>
The Wiki and ticketing-system are the most important. Any new system<br>
must start out with the content from the Trac wiki and all the Trac<br>
tickets migrated over.<br><br></blockquote><div><br></div><div>For the ticketing system, there are a few really useful features that it would be nice to preserve:</div><div><ul><li>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.</li><li>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.</li></ul><div>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.</div></div><div><br></div><div>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).</div><div><br></div><div>Thanks!</div><div>Jean-Paul</div><div><br></div></div></div>