Hi, doing our own issue tracker could be cool, but is yet-another-tool-to-maintain (not to take about the development time), so I rather not take that path… even if is cool :)
yes, having to register is a problem but I simplified the register process (into a one-step process): http://tracker.pharo.org/issues-register-service, so I think this is mitigated (I think the increase of registrations since I made the change is a proof). and FogBugz is pro… even if I dislike the UI a lot… and I think is too much for us… and I agree in general that is not the best for an open source project. But we have a tool for free, well maintained and managed. Instead just changing issue tracker I would like to think more in general. For instance, I would like to move the development process to github once we can finish/agree/implement a good way to doit. they it would have a lot of sense use the github issue tracker… but I’m not sure it has sense *before*. So there you go… before thinking on changing the issue tracker I would think which kind of process we want to support and just then think in which issue tracker we need :) Esteban > On 07 Oct 2015, at 09:00, Stephan Eggermont <[email protected]> wrote: > > On 07/10/15 08:27, Eliot Miranda wrote: >> BTW, at ParcPlace we implemented our own. It's not difficult and having >> something one can tailor is great. Pharo has the relevant web, database & >> server technology. It would be a great test of the system to implement its >> own issue tracker. > > http://gsoc2013.esug.org/projects/distributed-issue-tracker > > Stephan > > >
