Issue Tracker Choice

Now that the dust has settled after the move to FogBugz, maybe we should take another look. I know that we're already spread thin, but we all know it's a poor fit for our / OSS workflows, and I shudder to think at how many potential contributors gave up due to the IMHO significant barriers to entry.

Sean P. DeNigris <[hidden email]> writes:

> Now that the dust has settled after the move to FogBugz, maybe we should take
> another look. I know that we're already spread thin, but we all know it's a
> poor fit for our / OSS workflows, and I shudder to think at how many
> potential contributors gave up due to the IMHO significant barriers to
> entry.

could you please tell us what you don't like about FogBugz and what you
would like to see in another issue tracker? Moving all the issues,
writing the documentation, and updating our tools where difficult
enough, we should not do it lightly.

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Damien Cassou-2 wrote

could you please tell us what you don't like about FogBugz

The main thing is that it's not designed for open source projects. Requiring account creation before one can even search the open issues is a huge barrier. I would guess most new people will hit that wall and give up on sending us valuable bug reports.

but on the other hand
     - it is there
     - it works (even if I do not like the interface)
     - it is a pro tools (they should not close in the next 3 months).
     - so the message is also that we use a pro environment

Stef

Le 7/10/15 05:30, Sean P. DeNigris a écrit :

> On Oct 6, 2015, at 8:30 PM, Sean P. DeNigris <[hidden email]> wrote:
>
> Damien Cassou-2 wrote
>> could you please tell us what you don't like about FogBugz
>
> The main thing is that it's not designed for open source projects. Requiring
> account creation before one can even search the open issues is a huge
> barrier. I would guess most new people will hit that wall and give up on
> sending us valuable bug reports.


+1.  

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.


_,,,^..^,,,_ (phone)

> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/Issue-Tracker-Choice-tp4854002p4854106.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>

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

Hi Eliot,

Le 7 oct. 2015 à 08:27, Eliot Miranda a écrit :
Of course it is doable in Pharo but we will NOT go into this direction.
We have limited manpower and it is definitely not the place where it will be the more valuable. There are a lot of existing tools / services doing that. Moreover, it will be one more server to maintain...
That is also why we want to move slowly to git / gitHub because SmalltalkHub has no added value for us. I would rather say github will offer more services.

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

It would be interesting indeed.  However, I value much more an integration with git.

Alexandre