I've seen companies use some pretty amazingly awful tools with great success (Tom Pohl might know what I mean). I think that step 1 is getting them to agree to use *any* system. Once that's accomplished (the agreement part), identify one that meets your needs. I'd suggest turning off advanced features and only enable then after users adjust in order to lower the learning curve.<div>

<br></div><div>For example, in Trac or Redmine, just enable the wiki and the ultra basics of issues (Title, Description, Priority and Status). Later people can start using the due date field which will enable some other features. Then things like assignee and % done, etc.</div>

<div><br></div><div>If you start out with a bunch of complex features then the barrier to entry is higher and people are more likely to resist using it.<br><br><div class="gmail_quote">On Thu, Nov 17, 2011 at 9:53 AM, Josh More <span dir="ltr"><<a href="mailto:jmore@starmind.org">jmore@starmind.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I know that this is obvious to many, but I have to weigh in here... If<br>
you're tracking incidents, the critical element isn't architecture or<br>
feature set.  It's whether your people will actually use the system.<br>
So, instead of going off the recommendations of this list (which are<br>
good), spin up a few VMs and ask your team which one feels right.<br>
You're far more likely to build a successful security management team<br>
that way.<br>
<font color="#888888"><br>
-Josh<br>
</font><div><div></div><div class="h5"><br>
On Thu, Nov 17, 2011 at 9:49 AM, Matthew Nuzum <<a href="mailto:newz@bearfruit.org">newz@bearfruit.org</a>> wrote:<br>
> On Thu, Nov 17, 2011 at 8:41 AM, L. V. Lammert <<a href="mailto:lvl@omnitec.net">lvl@omnitec.net</a>> wrote:<br>
>><br>
>> On Thu, 17 Nov 2011, chris rheinherren wrote:<br>
>><br>
>> > I have a friend who is looking for, in his words:<br>
>> ><br>
>> > "Looking for a good open source incident tracking system, any ideas"<br>
>> ><br>
>> > so if you have any suggestions, fire away.<br>
>> ><br>
>> While not explicitly an 'incident tracking system', we have been using<br>
>> Redmine for years to track issues here; one of the best features is that<br>
>> it allows many diverse 'information models' by client/customer.<br>
>><br>
><br>
> +1 on redmine. I've also used Trac which is very similar. At one time I had<br>
> Trac configured so that you could create new tickets by sending an e-mail.<br>
> If you want an e-mail interface, RT is hard to beat (but also a bit harder<br>
> to setup and manage).<br>
> The main difference between redmine and trac is that redmine is ruby on<br>
> rails, trac is python.<br>
><br>
> --<br>
> Matthew Nuzum<br>
> newz2000 on freenode, skype, linkedin and twitter<br>
><br>
> ♫ You're never fully dressed without a smile! ♫<br>
><br>
</div></div><div><div></div><div class="h5">> _______________________________________________<br>
> Cialug mailing list<br>
> <a href="mailto:Cialug@cialug.org">Cialug@cialug.org</a><br>
> <a href="http://cialug.org/mailman/listinfo/cialug" target="_blank">http://cialug.org/mailman/listinfo/cialug</a><br>
><br>
><br>
_______________________________________________<br>
Cialug mailing list<br>
<a href="mailto:Cialug@cialug.org">Cialug@cialug.org</a><br>
<a href="http://cialug.org/mailman/listinfo/cialug" target="_blank">http://cialug.org/mailman/listinfo/cialug</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthew Nuzum<br>newz2000 on freenode, skype, linkedin and twitter<br><br><p>







</p><p><span>♫</span> You're never fully dressed without a smile! <span>♫</span></p><p></p><br>
</div>