Re: [QGIS-Developer] Post github issues migration clean ups - some proposals

2019-05-27 Thread Paolo Cavallini 
Good point, a blog post is most welcome. Jorge and the team behind the 
migration deserve this honour. Jorge, would you mind writing it? 
Ready to help if necessary.
Cheers.

Il 28 maggio 2019 01:06:59 CEST, Nyall Dawson  ha 
scritto:
>On Tue, 28 May 2019 at 07:45, Jorge Gustavo Rocha 
>wrote:
>>
>> Hi Alexis,
>>
>> There is no formal cleanup call, but in are in feature freeze until
>3.8
>> release on summer solstice (next June, 21th). That is why Nyall
>proposed
>> this move to GitHub right now, on this feature freeze period.
>>
>
>> In other words, we are already in this "round of cleanup"!
>>
>> So, let's go get them!
>
>On this note -- this could be a great chance for a blog post
>advertising the change and improved workflow/usability, and put
>forward a call for more volunteers to help us triage and clean up the
>queue?
>
>Nyall
>
>>
>> Regards,
>>
>> Jorge Gustavo
>>
>> Às 21:50 de 27/05/19, Alexis R.L. escreveu:
>> > Greetings,
>> >
>> > Out of curiosity, will there be a round of cleanup? Some issues are
>> > either quite old and possibly not reproducible while some other are
>the
>> > eternal crash when closing qgis.
>> >
>> >
>> > Alexis Roy-Lizotte
>> >
>> >
>> > Le lun. 27 mai 2019 à 05:35, Giovanni Manghi
>> > > a écrit :
>> >
>> > Hi,
>> >
>> >
>> >
>> > >
>> > > - "Database" label: should this be renamed "db manager", to
>> > > disambiguate from postgis/spatialite/etc issues, which
>instead belong
>> > > under "data providers"?
>> >
>> > agree
>> >
>> > >
>> > > - Can "CAD" be merged into "Digitising"? There's only a
>handful of
>> > > open issues, and I don't think it warrants a separate
>category. In
>> > > QGIS these two concepts are basically merged now anyway.
>> >
>> > not sure, maybe this was meant for the DXF/DWG import/export
>tools?
>> >
>> >
>> >
>> > > - "Editing": This label is very vague -- it's being used for
>> > > digitizing issues, project editing issues, copy/paste issues,
>and even
>> > > data provider issues. I'd argue we could drop this label and
>use other
>> > > existing, more specific labels instead
>> >
>> >
>> > on Redmine I always assumed that "editing" was to be used for
>issues
>> > regarding the edits of alphanumeric attributes while
>"digitizing" was
>> > to be used for issues about the geometry edits.
>> >
>> >
>> > -- G --
>> > ___
>> > QGIS-Developer mailing list
>> > QGIS-Developer@lists.osgeo.org
>
>> > List info:
>https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> > Unsubscribe:
>https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >
>> >
>> > ___
>> > QGIS-Developer mailing list
>> > QGIS-Developer@lists.osgeo.org
>> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> > Unsubscribe:
>https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >
>>
>> J. Gustavo
>> --
>> Jorge Gustavo Rocha
>> Departamento de Informática
>> Universidade do Minho
>> 4710-057 Braga
>> Tel: +351 253604480
>> Fax: +351 253604471
>> Móvel: +351 910333888
>> skype: nabocudnosor
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>___
>QGIS-Developer mailing list
>QGIS-Developer@lists.osgeo.org
>List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
Sorry for being short___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Post github issues migration clean ups - some proposals

2019-05-27 Thread Nyall Dawson 
On Mon, 27 May 2019 at 17:54, Régis Haubourg  wrote:
>
>> - How should we handle milestones now? We've been using them up till
>> now to tag PRs with their target version, and closing off milestones
>> as each release is made. Now we've got a whole lot of outdated
>> milestones (e.g. 2.14) because we have issues which were tagged to
>> these milestones from the old "affected version" property. I don't
>> think this is correct use of the milestone functionality, and would
>> like to see it used only for release management (i.e. if a bug has a
>> milestone, it's being targeted for fixing in that version*, so bug
>> reports should always have ONLY future version milestones, not past
>> versions). This would mean we'd need to change the affected version
>> handling to labels. Is everyone OK with this?
>>
>  milestone is a target, affected version is a descriptive information for a 
> bug. I don't see any milestone define in the repo. Did you already clean this 
> up? I'm not sure I get your point in fact, the affected version is only a 
> text comment in the issue body from what I see. Did I miss something?

Check https://github.com/qgis/QGIS/milestones

and e..g. tickets tagged with milestone 2.14:
https://github.com/qgis/QGIS/milestones/Version%202.14

I've closed off all the old milestones with no tickets, but I'm unsure
how to deal with the ones with open tickets. We really should only
have 3.8.0 / 3.4.9 / 3.10 and the "future" milestones open.

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Post github issues migration clean ups - some proposals

2019-05-27 Thread Nyall Dawson 
On Mon, 27 May 2019 at 19:35, Giovanni Manghi  wrote:
>
> Hi,
>
> > - "Editing": This label is very vague -- it's being used for
> > digitizing issues, project editing issues, copy/paste issues, and even
> > data provider issues. I'd argue we could drop this label and use other
> > existing, more specific labels instead
>
>
> on Redmine I always assumed that "editing" was to be used for issues
> regarding the edits of alphanumeric attributes while "digitizing" was
> to be used for issues about the geometry edits.

We've also got labels for both Attribute Table and Forms too. I'd
think issues relating to editing attributes in the table/editor
widgets/forms could better belong in those categories instead? (But
happy to take your lead)

Nyall



>
>
> -- G --
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Post github issues migration clean ups - some proposals

2019-05-27 Thread Nyall Dawson 
On Mon, 27 May 2019 at 09:06, Nyall Dawson  wrote:
>
> Hi all,
>
> Once again, many many thanks to the individuals behind the the recent
> issues migration. Fantastic job all round!
>
> I'd like to do some post-migration cleanups, but would like wider
> opinions on how to handle these:
>
> - We have two labels "bug" and "bug fix" which apply to issues and
> pull requests respectively. Can we combine these, and just use "bug"
> for bug fixing PRs? (There's a LOT of labels now)

Done

>
> - "Database" label: should this be renamed "db manager", to
> disambiguate from postgis/spatialite/etc issues, which instead belong
> under "data providers"?

Done

>
> - Can "CAD" be merged into "Digitising"? There's only a handful of
> open issues, and I don't think it warrants a separate category. In
> QGIS these two concepts are basically merged now anyway.

Based on discussion, I've renamed this to DXF/DWG for clarification

> - "Easy fix". Does anyone actually use this? Many of these are not
> "easy fixes" -- e.g. I've been chipping away at
> https://github.com/qgis/QGIS/issues/28195 since last year... it's
> probably about the hardest fix I've ever done in QGIS. No idea how
> this one gained the label!

Ok, seems there's a strong argument to leave this in place!

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Post github issues migration clean ups - some proposals

2019-05-27 Thread Nyall Dawson 
On Tue, 28 May 2019 at 07:45, Jorge Gustavo Rocha  wrote:
>
> Hi Alexis,
>
> There is no formal cleanup call, but in are in feature freeze until 3.8
> release on summer solstice (next June, 21th). That is why Nyall proposed
> this move to GitHub right now, on this feature freeze period.
>

> In other words, we are already in this "round of cleanup"!
>
> So, let's go get them!

On this note -- this could be a great chance for a blog post
advertising the change and improved workflow/usability, and put
forward a call for more volunteers to help us triage and clean up the
queue?

Nyall

>
> Regards,
>
> Jorge Gustavo
>
> Às 21:50 de 27/05/19, Alexis R.L. escreveu:
> > Greetings,
> >
> > Out of curiosity, will there be a round of cleanup? Some issues are
> > either quite old and possibly not reproducible while some other are the
> > eternal crash when closing qgis.
> >
> >
> > Alexis Roy-Lizotte
> >
> >
> > Le lun. 27 mai 2019 à 05:35, Giovanni Manghi  > > a écrit :
> >
> > Hi,
> >
> >
> >
> > >
> > > - "Database" label: should this be renamed "db manager", to
> > > disambiguate from postgis/spatialite/etc issues, which instead belong
> > > under "data providers"?
> >
> > agree
> >
> > >
> > > - Can "CAD" be merged into "Digitising"? There's only a handful of
> > > open issues, and I don't think it warrants a separate category. In
> > > QGIS these two concepts are basically merged now anyway.
> >
> > not sure, maybe this was meant for the DXF/DWG import/export tools?
> >
> >
> >
> > > - "Editing": This label is very vague -- it's being used for
> > > digitizing issues, project editing issues, copy/paste issues, and even
> > > data provider issues. I'd argue we could drop this label and use other
> > > existing, more specific labels instead
> >
> >
> > on Redmine I always assumed that "editing" was to be used for issues
> > regarding the edits of alphanumeric attributes while "digitizing" was
> > to be used for issues about the geometry edits.
> >
> >
> > -- G --
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org 
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> >
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
>
> J. Gustavo
> --
> Jorge Gustavo Rocha
> Departamento de Informática
> Universidade do Minho
> 4710-057 Braga
> Tel: +351 253604480
> Fax: +351 253604471
> Móvel: +351 910333888
> skype: nabocudnosor
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Post github issues migration clean ups - some proposals

2019-05-27 Thread Jorge Gustavo Rocha 
Hi Alexis,

There is no formal cleanup call, but in are in feature freeze until 3.8
release on summer solstice (next June, 21th). That is why Nyall proposed
this move to GitHub right now, on this feature freeze period.

In other words, we are already in this "round of cleanup"!

So, let's go get them!

Regards,

Jorge Gustavo

Às 21:50 de 27/05/19, Alexis R.L. escreveu:
> Greetings,
> 
> Out of curiosity, will there be a round of cleanup? Some issues are
> either quite old and possibly not reproducible while some other are the
> eternal crash when closing qgis.
> 
> 
> Alexis Roy-Lizotte
> 
> 
> Le lun. 27 mai 2019 à 05:35, Giovanni Manghi  > a écrit :
> 
> Hi,
> 
> 
> 
> >
> > - "Database" label: should this be renamed "db manager", to
> > disambiguate from postgis/spatialite/etc issues, which instead belong
> > under "data providers"?
> 
> agree
> 
> >
> > - Can "CAD" be merged into "Digitising"? There's only a handful of
> > open issues, and I don't think it warrants a separate category. In
> > QGIS these two concepts are basically merged now anyway.
> 
> not sure, maybe this was meant for the DXF/DWG import/export tools?
> 
> 
> 
> > - "Editing": This label is very vague -- it's being used for
> > digitizing issues, project editing issues, copy/paste issues, and even
> > data provider issues. I'd argue we could drop this label and use other
> > existing, more specific labels instead
> 
> 
> on Redmine I always assumed that "editing" was to be used for issues
> regarding the edits of alphanumeric attributes while "digitizing" was
> to be used for issues about the geometry edits.
> 
> 
> -- G --
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org 
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> 
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

J. Gustavo
-- 
Jorge Gustavo Rocha
Departamento de Informática
Universidade do Minho
4710-057 Braga
Tel: +351 253604480
Fax: +351 253604471
Móvel: +351 910333888
skype: nabocudnosor
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Post github issues migration clean ups - some proposals

2019-05-27 Thread Alexis R.L. 
Greetings,

Out of curiosity, will there be a round of cleanup? Some issues are either
quite old and possibly not reproducible while some other are the eternal
crash when closing qgis.


Alexis Roy-Lizotte


Le lun. 27 mai 2019 à 05:35, Giovanni Manghi  a
écrit :

> Hi,
>
>
>
> >
> > - "Database" label: should this be renamed "db manager", to
> > disambiguate from postgis/spatialite/etc issues, which instead belong
> > under "data providers"?
>
> agree
>
> >
> > - Can "CAD" be merged into "Digitising"? There's only a handful of
> > open issues, and I don't think it warrants a separate category. In
> > QGIS these two concepts are basically merged now anyway.
>
> not sure, maybe this was meant for the DXF/DWG import/export tools?
>
>
>
> > - "Editing": This label is very vague -- it's being used for
> > digitizing issues, project editing issues, copy/paste issues, and even
> > data provider issues. I'd argue we could drop this label and use other
> > existing, more specific labels instead
>
>
> on Redmine I always assumed that "editing" was to be used for issues
> regarding the edits of alphanumeric attributes while "digitizing" was
> to be used for issues about the geometry edits.
>
>
> -- G --
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Post github issues migration clean ups - some proposals

2019-05-27 Thread Régis Haubourg 
Hi,

Le lun. 27 mai 2019 à 01:06, Nyall Dawson  a écrit :

> Hi all,
>
> Once again, many many thanks to the individuals behind the the recent
> issues migration. Fantastic job all round!
>
+1 !

>
> I'd like to do some post-migration cleanups, but would like wider
> opinions on how to handle these:
>
> - We have two labels "bug" and "bug fix" which apply to issues and
> pull requests respectively. Can we combine these, and just use "bug"
> for bug fixing PRs? (There's a LOT of labels now)
>
+1

>
> - "Database" label: should this be renamed "db manager", to
> disambiguate from postgis/spatialite/etc issues, which instead belong
> under "data providers"?
>
+1

>
> - Can "CAD" be merged into "Digitising"? There's only a handful of
> open issues, and I don't think it warrants a separate category. In
> QGIS these two concepts are basically merged now anyway.
>
+1

>
> - "Easy fix". Does anyone actually use this? Many of these are not
> "easy fixes" -- e.g. I've been chipping away at
> https://github.com/qgis/QGIS/issues/28195 since last year... it's
> probably about the hardest fix I've ever done in QGIS. No idea how
> this one gained the label!
>
Let's keep the label as an attempt to help new contributors to board in.
Core dev's shouldn't be shy about removing the "Easy fix" tag when they
know it's not easy :)

>
> - "Editing": This label is very vague -- it's being used for
> digitizing issues, project editing issues, copy/paste issues, and even
> data provider issues. I'd argue we could drop this label and use other
> existing, more specific labels instead
>
+1

>
> - "Feature request" / "Feature": I'm not sure how we'd go about
> merging these two categories, but it seems strange to have the two
> separate.
>
+1 . the label list was discussed only using the redmine candidates and we
forgot to check duplicates already in the QGIS github repo.. Let's solve
this.

>
> - How should we handle milestones now? We've been using them up till
> now to tag PRs with their target version, and closing off milestones
> as each release is made. Now we've got a whole lot of outdated
> milestones (e.g. 2.14) because we have issues which were tagged to
> these milestones from the old "affected version" property. I don't
> think this is correct use of the milestone functionality, and would
> like to see it used only for release management (i.e. if a bug has a
> milestone, it's being targeted for fixing in that version*, so bug
> reports should always have ONLY future version milestones, not past
> versions). This would mean we'd need to change the affected version
> handling to labels. Is everyone OK with this?
>
>  milestone is a target, affected version is a descriptive information for
a bug. I don't see any milestone define in the repo. Did you already clean
this up? I'm not sure I get your point in fact, the affected version is
only a text comment in the issue body from what I see. Did I miss something?


> Nyall
>
> * Ideally, we'd block non-core-contributors from setting milestones
> for issues, to avoid reporters just tagging their issue with an
> upcoming milestone as a rude way of saying "fix my stuff for me"
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Post github issues migration clean ups - some proposals

2019-05-26 Thread DelazJ 
Hi

"Easy fix" is what introduced me to the QGIS code (and maybe to GH). It
makes things less intimidating, particularly when you are not a developer
(not all the issues require to be a master in coding) and this is what i
from time to time use to check in redmine. And TBH, this is the first
filter I applied to the new list in GH. The issue is that in Redmine, the
easy status was often decided by the reporter and I'm not sure they always
knew the internals of the code before tagging (though i might admit that
it's not simple to identify what is easy for others).

About the weirdness to keep bugs that are easy to fix, yes it's weird but
it's the price to pay to attract new contributors. And there are issues
that don't really hurt the project if kept unfixed. In docs we have an easy
label that we spend as much time to label and add guidance than we'd spend
to fix the issue but from time to time (unfortunately not as frequent that
i wish) there's a new contributor who picks one and fix it. And at that
moment, you see the benefit.
One thing we can do, or maybe did I miss it for the recent releases, is to
make a real call when we move to feature freeze. I did not see a call for
this one and got the information in irc; not all potential contributors
follow the countdown at qgis.org. Without a clear call inviting testers,
extending bug fixes time would not have more benefit. But other than
testers, we can add a focus on the "easy fix" label inviting people that
want to contribute to give them a shot. And if a week before the release
there still are "easy fix" issues, core devs can clean them if they want.

just my 2cts
Harrissou (a non dev that is often happy to fix code and want the process
to be easy for him)

Le lun. 27 mai 2019 à 06:30, Denis Rouzaud  a
écrit :

> Hi all,
>
> May I also suggest to create a "wontfix" label?
>
> Le dim. 26 mai 2019 à 21:46, Denis Rouzaud  a
> écrit :
>
>>
>>
>> Le dim. 26 mai 2019 à 21:38, Nyall Dawson  a
>> écrit :
>>
>>> On Mon, 27 May 2019 at 11:43, Denis Rouzaud 
>>> wrote:
>>>
>>> > +1. But, we should indeed have a strict definition of when adding the
>>> milestone (someone is taking care of the fix or every time it's just
>>> considered as important). I'd rather keep milestones for PRs and maybe
>>> bring back the idea of "blocker" tag.
>>>
>>> I think it should only be defined by someone actually assigned to the
>>> bug. E.g. if I self-assign a bunch of bugs I'm actively working on,
>>> I'd like to be able to use milestones to self-manage these...
>>>
>>
>> I see, I'm just afraid to see too many issues left-open with a past
>> milestone.
>> But we can give it a try I guess.
>>
>>
>>>
>>> Nyall
>>>
>>>
>>> >>
>>> >>
>>> >> Nyall
>>> >>
>>> >> * Ideally, we'd block non-core-contributors from setting milestones
>>> >> for issues, to avoid reporters just tagging their issue with an
>>> >> upcoming milestone as a rude way of saying "fix my stuff for me"
>>> >> ___
>>> >> QGIS-Developer mailing list
>>> >> QGIS-Developer@lists.osgeo.org
>>> >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Post github issues migration clean ups - some proposals

2019-05-26 Thread Denis Rouzaud 
Hi all,

May I also suggest to create a "wontfix" label?

Le dim. 26 mai 2019 à 21:46, Denis Rouzaud  a
écrit :

>
>
> Le dim. 26 mai 2019 à 21:38, Nyall Dawson  a
> écrit :
>
>> On Mon, 27 May 2019 at 11:43, Denis Rouzaud 
>> wrote:
>>
>> > +1. But, we should indeed have a strict definition of when adding the
>> milestone (someone is taking care of the fix or every time it's just
>> considered as important). I'd rather keep milestones for PRs and maybe
>> bring back the idea of "blocker" tag.
>>
>> I think it should only be defined by someone actually assigned to the
>> bug. E.g. if I self-assign a bunch of bugs I'm actively working on,
>> I'd like to be able to use milestones to self-manage these...
>>
>
> I see, I'm just afraid to see too many issues left-open with a past
> milestone.
> But we can give it a try I guess.
>
>
>>
>> Nyall
>>
>>
>> >>
>> >>
>> >> Nyall
>> >>
>> >> * Ideally, we'd block non-core-contributors from setting milestones
>> >> for issues, to avoid reporters just tagging their issue with an
>> >> upcoming milestone as a rude way of saying "fix my stuff for me"
>> >> ___
>> >> QGIS-Developer mailing list
>> >> QGIS-Developer@lists.osgeo.org
>> >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Post github issues migration clean ups - some proposals

2019-05-26 Thread Denis Rouzaud 
Le dim. 26 mai 2019 à 21:38, Nyall Dawson  a écrit :

> On Mon, 27 May 2019 at 11:43, Denis Rouzaud 
> wrote:
>
> > +1. But, we should indeed have a strict definition of when adding the
> milestone (someone is taking care of the fix or every time it's just
> considered as important). I'd rather keep milestones for PRs and maybe
> bring back the idea of "blocker" tag.
>
> I think it should only be defined by someone actually assigned to the
> bug. E.g. if I self-assign a bunch of bugs I'm actively working on,
> I'd like to be able to use milestones to self-manage these...
>

I see, I'm just afraid to see too many issues left-open with a past
milestone.
But we can give it a try I guess.


>
> Nyall
>
>
> >>
> >>
> >> Nyall
> >>
> >> * Ideally, we'd block non-core-contributors from setting milestones
> >> for issues, to avoid reporters just tagging their issue with an
> >> upcoming milestone as a rude way of saying "fix my stuff for me"
> >> ___
> >> QGIS-Developer mailing list
> >> QGIS-Developer@lists.osgeo.org
> >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Post github issues migration clean ups - some proposals

2019-05-26 Thread Nyall Dawson 
On Mon, 27 May 2019 at 11:43, Denis Rouzaud  wrote:

> +1. But, we should indeed have a strict definition of when adding the 
> milestone (someone is taking care of the fix or every time it's just 
> considered as important). I'd rather keep milestones for PRs and maybe bring 
> back the idea of "blocker" tag.

I think it should only be defined by someone actually assigned to the
bug. E.g. if I self-assign a bunch of bugs I'm actively working on,
I'd like to be able to use milestones to self-manage these...

Nyall


>>
>>
>> Nyall
>>
>> * Ideally, we'd block non-core-contributors from setting milestones
>> for issues, to avoid reporters just tagging their issue with an
>> upcoming milestone as a rude way of saying "fix my stuff for me"
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Post github issues migration clean ups - some proposals

2019-05-26 Thread Denis Rouzaud 
Hi Nyall,

I generally completely agree with all the points you raised, some comments
below

Le dim. 26 mai 2019 à 18:06, Nyall Dawson  a écrit :

> Hi all,
>
> Once again, many many thanks to the individuals behind the the recent
> issues migration. Fantastic job all round!
>
> I'd like to do some post-migration cleanups, but would like wider
> opinions on how to handle these:
>
> - We have two labels "bug" and "bug fix" which apply to issues and
> pull requests respectively. Can we combine these, and just use "bug"
> for bug fixing PRs? (There's a LOT of labels now)
>
> - "Database" label: should this be renamed "db manager", to
> disambiguate from postgis/spatialite/etc issues, which instead belong
> under "data providers"?
>
> - Can "CAD" be merged into "Digitising"? There's only a handful of
> open issues, and I don't think it warrants a separate category. In
> QGIS these two concepts are basically merged now anyway.


> - "Easy fix". Does anyone actually use this? Many of these are not
> "easy fixes" -- e.g. I've been chipping away at
> https://github.com/qgis/QGIS/issues/28195 since last year... it's
> probably about the hardest fix I've ever done in QGIS. No idea how
> this one gained the label!
>

I'm +0 here. I liked the idea of easy fixes for new comers. On the other
hand, it's a bit weird to keep "easy" fixed issues.

>
> - "Editing": This label is very vague -- it's being used for
> digitizing issues, project editing issues, copy/paste issues, and even
> data provider issues. I'd argue we could drop this label and use other
> existing, more specific labels instead
>
> - "Feature request" / "Feature": I'm not sure how we'd go about
> merging these two categories, but it seems strange to have the two
> separate.
>
> - How should we handle milestones now? We've been using them up till
> now to tag PRs with their target version, and closing off milestones
> as each release is made. Now we've got a whole lot of outdated
> milestones (e.g. 2.14) because we have issues which were tagged to
> these milestones from the old "affected version" property. I don't
> think this is correct use of the milestone functionality, and would
> like to see it used only for release management (i.e. if a bug has a
> milestone, it's being targeted for fixing in that version*, so bug
> reports should always have ONLY future version milestones, not past
> versions). This would mean we'd need to change the affected version
> handling to labels. Is everyone OK with this?
>

+1. But, we should indeed have a strict definition of when adding the
milestone (someone is taking care of the fix or every time it's just
considered as important). I'd rather keep milestones for PRs and maybe
bring back the idea of "blocker" tag.

>
> Nyall
>
> * Ideally, we'd block non-core-contributors from setting milestones
> for issues, to avoid reporters just tagging their issue with an
> upcoming milestone as a rude way of saying "fix my stuff for me"
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Post github issues migration clean ups - some proposals

2019-05-26 Thread Nyall Dawson 
Hi all,

Once again, many many thanks to the individuals behind the the recent
issues migration. Fantastic job all round!

I'd like to do some post-migration cleanups, but would like wider
opinions on how to handle these:

- We have two labels "bug" and "bug fix" which apply to issues and
pull requests respectively. Can we combine these, and just use "bug"
for bug fixing PRs? (There's a LOT of labels now)

- "Database" label: should this be renamed "db manager", to
disambiguate from postgis/spatialite/etc issues, which instead belong
under "data providers"?

- Can "CAD" be merged into "Digitising"? There's only a handful of
open issues, and I don't think it warrants a separate category. In
QGIS these two concepts are basically merged now anyway.

- "Easy fix". Does anyone actually use this? Many of these are not
"easy fixes" -- e.g. I've been chipping away at
https://github.com/qgis/QGIS/issues/28195 since last year... it's
probably about the hardest fix I've ever done in QGIS. No idea how
this one gained the label!

- "Editing": This label is very vague -- it's being used for
digitizing issues, project editing issues, copy/paste issues, and even
data provider issues. I'd argue we could drop this label and use other
existing, more specific labels instead

- "Feature request" / "Feature": I'm not sure how we'd go about
merging these two categories, but it seems strange to have the two
separate.

- How should we handle milestones now? We've been using them up till
now to tag PRs with their target version, and closing off milestones
as each release is made. Now we've got a whole lot of outdated
milestones (e.g. 2.14) because we have issues which were tagged to
these milestones from the old "affected version" property. I don't
think this is correct use of the milestone functionality, and would
like to see it used only for release management (i.e. if a bug has a
milestone, it's being targeted for fixing in that version*, so bug
reports should always have ONLY future version milestones, not past
versions). This would mean we'd need to change the affected version
handling to labels. Is everyone OK with this?

Nyall

* Ideally, we'd block non-core-contributors from setting milestones
for issues, to avoid reporters just tagging their issue with an
upcoming milestone as a rude way of saying "fix my stuff for me"
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer