Proposal to shift bug/issue tracking work to GitHub Issues for QGIS 3x+

@nyalldawson So your preference would be for a motion which says "Let us make the hub.qgis.org site read only and from now on use GitHub issues for issue tracking"?

I'd say block new issues. Leave it editable for existing issues so that we can still close/comment/ask for feedback on them?

Indeed might be a better move. It migh avoid confusion, and we will have the benefit of having all new features on github.

Ok since only Nyall has voted, let me withdraw the motion in favour of a 'one system' option.

Ok thanks for your inputs @nyalldawson I have updated the proposal accordingly. Those who wish to hold out for GitLab or some other platform feel free to vote no, but please join the process of actually making your preferred platform happen.

OK so I'm going to vote yes mainly because I would like the experience of reporting issues to be better. I would also like our project management/planning tools to be better and there is a lot of tooling around GitHub for that.

I might support a move to gitlad in the future however it's a large endeavour and I don't think it's wise to do it yet.

QGIS Australia User group has passed the question onto members and will provide a vote reflecting the majority by Friday 2/2/2018

QGIS Italy user group has voted for Redmine.
I would be against keeping a double system (it reminds me of the old times when so many things were doubled in QGIS ). I think this would be terribly confusing for users, and cumbersome to deal with for devs.

As pointed out by Paolo, the Italian user group is in favor of Readmine. The discussion is mainly on not loosing the ticket history. I think having 2 different systems (Readmine + GH) at the same time could enlarge the entropy and lead to a lot of confusion. So whatever agreement we find I'm just against a double system.

If we block new issues in Readmine from now on, what about the LTR release? 2.18 is maybe the most "delicate" LTR because of the QGIS 3 release: potentially lot of users can report other issues for 2.18 in the future and with a double system there could be a lot of double work for devs.

I feel strongly uncomfortable with this vote : first there is no consensus neither convergence on the subject in the community. Then, we have a yes/no vote on a single alternative, whereas there are multiple alternative possible that should be studied, and this one ( GH migration) is clearly not the one gaining most favors.
Also, there is no action plan and resources linked to this decision, which is also a problem IMHO.
And I have a strong problem with migration to a proprietary solution.

Honestly, I'm surprised to find that there should be a vote while the last comment in the mailing-list discussion was Giovanni announcing this topic to the discussion held in Madeira. Worrying that it'd be an endless discussion?
Anyway, question has been passed to French QGIS User Group...

Hi, when I said "talk about it in Funchal" I think that this vote had not been published yet, if is not so I apologize.

@delazj I was asked by @denisrouzaud to raise it to a vote. I don't think it is an unreasonable request - if the consensus is 'just move to github' then it can cut a lot of wasted time in discussion of something that the majority of voters do not wish to happen. If the consensus is 'no we want to move to gitlab or stay on redmine' then at least the discussion in Madeira can go ahead knowing there is a mandate to make the proposed changes.

I've passed the question onto the USA user group for consensus. I too will provide a vote by Friday 2/2.

I've also passed the question to the QGIS-DE members. Our vote will be provided by the weekend.

asked in spanish community, I'll use my vote conform to their decisions because their are still not a formal user group

@wernermacho Hi! Thanks for your comments! I'd just like to respond to your comment by repeating part of my email on the PSC list:

The whole issue of issue trackers is not a ​new or sudden topic - it has been dragging on for years. The PSC made a decision in Essen last year to stick to Redmine, primarily for pragmatic reasons - we would all like to use something more modern in an ideal world. It was probably not a popular decision and the topic never 'went away'. We have also had many face-to-face discussions on it at previous hackfests without resolution.

I'd also like to point out that our issue tracker affects our whole community, not developers and IMHO using the QGIS Voting Membership to make the decision is a broader and more inclusive way to do it that a small set of us sitting face to face in Madeira.

Using a community vote is supposed to be the mechanism to make decisions, even to supercede the PSC if needed. So whether the decision is yes or no to this vote is OK, but let's find a way to actually make a decision so that we can move out of limbo.

Anyway it is great to see our voting community at work, thanks again for your comments, keep voting everyone!

Regards

Tim

Hi @vincentpicavet, thanks for casting your vote! I'd also like to address some of your comments:

Multiple reasons : no clear consensus neither convergence in the community.

That is the intent of this vote (and subsequent votes in this thread if relevant), to establish consensus. I think it is very unlikely that we will reach a clear, inclusive consensus via mailing list discussions.

A vote now seems prematurate.

I think it is a very good time to bring it to a vote - it gives us an opportunity to provide a clear path for what we will do in terms of our tracker (keep on redmine or switch to something new) along with the release of QGIS 3.0. Also as mentioned, this discussion has been ongoing for years, 2018 seems like a good year to resolve it :-)

My opinion depends on the conditions of a migration ( keeping history?, multiple instances?) .

Keeping history in Redmine and starting a new tracker in GitHub is the proposal here. If we get a no vote we will keep proposing alternatives (e.g. same protocol but use GitLab instead of GitHub) until one is approved.

And -1 for GH and +1 for Opensource GitLab.

Ok - as mentioned if we get a No vote here I will table the next proposal for GitLab instead of GitHub.

Thanks so much for your inputs!

Regards

Tim

@martindobias Concerning tickets ID, a simple ID is to generate blank issues up to 30'000 in github with a link to corresponding issue in Redmine. It's very simple ans easy with GH API. Although that would not work for first 7'000 as these numbers are pull requests, on the other hand these are really old issues.

The Portuguese user group has also been inquired, answer coming tomorrow (leaning towards a "yes").

For a long time I have been very vocal about leaving Redmine, in first place because the platform was barely usable, but also because it makes anyway much more sense have code, docs and trackers all in one place (for both developers and users). Since the Redmine server has been updated (along with Redmine version update) usability/speed has improved a lot, but this has not solved the problem that is cumbersome to have separated platforms. I'm overall in favor to move to GH or Gitlab but as other feel very uncomfortable in taking a decision without a consensus and/or another face to face discussion (the other have been in Las Palmas).

QGIS Italian user group officially voted for Readmine.

Summarized the german QGIS user group members are against this proposal. This refusal might not be once and for all, but at the moment they don't feel an urgend need to migrate and seem mostly satisfied with the usability of redmine. But most important to them is, that such a migration has to be well tested to prove it's benefits, feasibility and innocuousness - which they don't see as given currently.

@thomasschuttenberg Thanks for your feedback from QGIS-DE - really great to have it!