What don't you switch to GitHub issues

[Meta]

On Sunday, 31 December 2017 at 11:18:26 UTC, Seb wrote:
> On Saturday, 30 December 2017 at 02:50:48 UTC, Adam D. Ruppe 
> wrote:
>> Bugzilla was the most well-known solution at the time. Keep in 
>> mind the D bugzilla has been around since 2006. As far as I 
>> understand it, migration at this point is deemed a big pain.
>
> No it wouldn't be a big pain. There are many tools for 
> automatically migrating issues from Bugzilla. The only thing 
> depending on Bugzilla is the changelog generator, but it's API 
> calls to Bugzilla can be replaced with GitHub API calls within 
> an hour.
> So the entire migration could be easily done in a lot less than 
> a day.
>
> The only reason we still use Bugzilla is that the core people 
> are used to it. Here are a couple of the common arguments:
>
> 1) Bugzilla is our, we don't want to depend on GitHub
>
> The D ecosystem already heavily depends on GitHub. Exporting 
> the issues from GitHub would be easy. Besides there is only one 
> person with access to the Bugzilla server.
>
> 2) GitHub only has per registry issues
>
> Bugzilla uses components too, they don't support global issues 
> either. Besides if that's required one could easily create a 
> meta repository for such global tasks.
>
> 3) Bugzilla's issue tracker is more sophisticated
>
> Sure, but does this help when you loose out on many 
> contributors?
> GitHub even has build tools and sites that let anyone discover 
> "easy" issues if they are labeled accordingly. It's free 
> marketing.
>
> FYI I asked the same question 1 1/2 years ago: 
> https://forum.dlang.org/post/ezldcjzpmsnxvvncncsi@forum.dlang.org
>
> Since then, for example, GitHub got voting for issues, but 
> Bugzilla lost it.

I wholeheartedly agree. The customer is always right, especially 
when you're trying to get them to donate their time to an open 
source project. It's more essential than ever that we lower 
barriers to participation; if Github issues is the hip new thing 
all the kids like, then we need to switch to that. We shouldn't 
be constantly switching to the shiniest new toy, but nor should 
we stubbornly stick to a piece of software that was built (and it 
looks it) in '90s.

Or at least we should if we're trying to attract the kind of 
people for whom not using Github is a deal breaker. Older 
C++/Java programmers likely don't care, but younger 
Python/Ruby/JS users will.