[ckan-dev] Github Issues

Wed Jan 9 21:36:39 UTC 2013

I'm not sure why it's necessary to tag things as wontfix, invalid or
duplicate. Tags are mainly useful for finding/grouping/sorting, and I'm not
really sure that there's much of a demand to go back and find all of the
tickets that we have decided not to fix. The only place that this is useful
is in the ticket itself, and it seems just as easy to add this as a
comment, particularly as a comment will generally be needed anyway if a
ticket is being closed.

I agree that we should add a tag for bug/defect, and get rid of low and
medium.

John

On 9 January 2013 22:03, Sean Hammond <sean.hammond at okfn.org> wrote:

> I agree lets try to keep the number of issues down and the tags to just
> what we really need. I think we need to tweak the tags though:
>
> - bug is a useful tag for when I come across a bug in master that I'm
>   not going to fix right now and need to file it somewhere, even though
>   we want to keep the number of issues down I do think we want to keep
>   track of all bugs we know about in ckan not just the ones we're
>   planning to fix this sprint or something, so the tag is useful for
>   distinguishing these issues from other types of issues.
>
>   bugs can always be tagged wontfix and closed, if they seem low
>   priority and unlikely to be worked on.
>
> - I think question and enhancement are also useful for similar reasons.
>
> - invalid, wontfix and duplicate are useful for keeping the number of
>   issues down, you just slap one of these tags on an issue and close it!
>
>   For example wishlist issues for features we're never going to
>   implement will inevitably appear, now you can tag them wontfix and
>   close them.
>
> - medium should go seems meaningless
>
> - low should go, seems a way to tag things and then let them sit open
>   forever, just be honest and tag them wontfix and close them instead.
>
>   So the only priority would be HIGH, everything else is normal
>
> - Issues that _must_ be done for ckan 2.0 could be tagged ckan 2.0 and
>   HIGH, that way we can use version number tags to keep track of what
>   bugs affect what versions, what features are planned for what
>   versions, etc. not just the stuff that is critical for the release.
>
> On Wed, Jan 09, 2013 at 01:51:10PM +0000, Toby Dacre wrote:
> > I have to say I'm for the absolute minimum number of tags we can get away
> > with eg I think medium priority should go.
> >
> > I'm also keen to keep the issues number as low as possible so things like
> > wishlist stuff shouldn't be there just currently needed things.
> > maybe that's just me
> >
> > Toby
> >
> > On 9 January 2013 12:52, Sean Hammond <sean.hammond at okfn.org> wrote:
> >
> > > Any chance we can have the default github issues tags (bug,
> enhancement,
> > > duplicate, invalid, question, wontfix) back? These seem useful to me,
> > > maybe it's just that I like tagging things, but making an issue and
> > > leaving it completely untagged/unsorted seems like it's just going to
> > > get lost:
> > >
> > > bug/enhancement -- useful for e.g. seeing what important bugs still
> need
> > > to be fixed for a release, making a list of "known issues" for a CKAN
> > > release, seeing what feature requests there are to consider for next
> > > release
> > >
> > > question -- useful to separate support requests from bug reports and
> > > feature requests, in case people start using github to ask support
> > > questions
> > >
> > > duplicate, invalid, wontfix -- useful to use just before you close an
> > > issue so people can see why it was closed, perhaps enter a comment
> > > saying why as well, seems equivalent to on trac where you could set the
> > > status to one of fixed, wontfix, duplicate, etc.
> > >
> > > On Tue, Dec 18, 2012 at 04:41:13PM +0000, David Raznick wrote:
> > > > Hello All
> > > >
> > > > I have turned github issues on for CKAN.  Good news is that all pull
> > > > requests are already there and makes them easy to see which ones are
> > > > assigned to you.
> > > >
> > > > I have only added 4 labels. Priorty based ones and a CKAN 2.0 is for
> > > stuff
> > > > that *must* get fixed for the release.
> > > >
> > > > We will not yet move over any tickets from trac and we hope to keep
> the
> > > > issue list clean and try and avoid anything that we do not intend to
> work
> > > > on over the next couple of months (maximum).  All future and nice to
> have
> > > > ideas should be discussed somewhere else in order to avoid clutter
> and
> > > they
> > > > should be purged regularly.
> > > >
> > > > A good reference to understand how it works seems to be this blog
> > > article.
> > > >
> > > > https://github.com/blog/831-issues-2-0-the-next-generation
> > > >
> > > > It tells you how to make your commit messages to come up/close an
> issue.
> > > >
> > > > Please feedback any further tips that are useful.
> > > >
> > > > Thanks
> > > >
> > > > David
> > >
> > > > _______________________________________________
> > > > ckan-dev mailing list
> > > > ckan-dev at lists.okfn.org
> > > > http://lists.okfn.org/mailman/listinfo/ckan-dev
> > > > Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
> > >
> > >
> > > _______________________________________________
> > > ckan-dev mailing list
> > > ckan-dev at lists.okfn.org
> > > http://lists.okfn.org/mailman/listinfo/ckan-dev
> > > Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
> > >
>
> > _______________________________________________
> > ckan-dev mailing list
> > ckan-dev at lists.okfn.org
> > http://lists.okfn.org/mailman/listinfo/ckan-dev
> > Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20130109/91ba37ff/attachment-0001.html>