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 <stephan@stack.nl> 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