Improved issue/task management

[Dominik Ruf]

Thomas De Schampheleire <patrickdepinguin at gmail.com> schrieb am Mo., 24.
Okt. 2016 um 20:34 Uhr:

> Hi Dominik, all,
>
> On Sun, Oct 23, 2016 at 1:38 PM, Dominik Ruf <dominikruf at gmail.com> wrote:
> > Hi all,
> >
> > I strongly believe we need to improve the issue and task management in
> our
> > project.
> > Currently we use a mix of bitbucket wiki pages, bitbucket/kallithea pull
> > request/changeset comments and bitbucket issue tracker.
>
> I agree that the current situation is not optimal. While it works in
> this 'unorganized' way, it could perhaps be made better. Some of this
> has also been discussed on the developer gathering we held in the
> beginning of this year (present were Mads, Søren, Andrew, Jan Heylen,
> Mathias De Maré and myself).
>
> Some points I think about:
>
> - for code contribution, the goal should be to use Kallithea itself.
> People like to call it 'eat your own dog food'. So while currently
> some people use Bitbucket pull requests or to a lesser extent send
> patches to the mailing list, I have been using this method and so far
> it worked fine. An open point here was how users would get access:
> auto-registration with automatic acceptance, manual acceptance, or
> admin-only sign-up ? I think this is something we should unblock and
> continue with. As a result, Bitbucket PRs would no longer be used.
>
> +10 for eating our own dog food
But in my view there 2 things that need to be done before we can do that.
1. open auto-registration.
2. everyone needs a personal space/folder where he/she can create a fork
and there be able to create a pull request.


> - issues: regardless of where they are stored, we currently have too
> many open issues where no-one really looks at. Some of them are actual
> issues, some are really suggestions for improvement. Since there are
> only a few active contributors, the risk is that this list just keeps
> growing without fixing any of them.
> At some point I scanned over them, closed some that were no longer
> relevant or got no response after querying, and marked some of the
> open ones with tags, like 'documentation'. But it does not help in the
> big picture if we don't actively work at them, or be more strict in
> which type of issues we accept in the tracker: only bugs, or also
> 'suggestions'?
> Regarding suggestions: how to decide whether it is a 'good'
> suggestion? Sometimes a user 'suggests' a change but the core
> developers don't think it fits in Kallithea as we see it. We need to
> make sure that we have some guidelines on how we want Kallithea to be,
> so we can refer to these guidelines in a more 'objective' way, and as
> such avoid giving the impression that we don't welcome any suggestion.
> In Buildroot, a project I have been active in before, one of the goals
> is simplicity. Any suggestion or patch is checked against that goal.
> If the added complexity is too large, we request a rework or plainly
> reject the idea. I would say it works well, because the goals are
> stated.
>
I think a big reason for this is that fact that bitbucket doesn't give you
much options on how to manage (group, order or filter) the issues.
My hope is that another tool will help with this.
Very important to me is to be able to divide a big 'user story' into
multiple smaller tasks and to filter issues. This helps me to concentrate
on one topic. On bitbucket I see only one big list of unresolved issues and
I don't know where to start.
In the scenario you describe we could create different kinds of issues. A
'suggestion' which the user reports and only after it has been discussed
will it become an 'user story' that we set on our 'road map'.


> - Mads and I had some kind of disagreement on what to do with an issue
> tracker: I was in favor of striving towards 0 issues, Mads said this
> was unrealistic and maybe not even worth striving for (he may be right
> on the first point :-) )
>
> - Since Mads also preferred not using the issue tracker for
> suggestions (and I kind of followed him there) I started using the
> wiki a bit more for some specific stuff, like open tasks related to
> pytest migration, turbogears migration, ...
> Also, I pushed to getting more of a roadmap, rather than just
> 'wandering about'. In particular, I have some time to spare (albeit
> little) that I can and want to dedicate to the project, but preferably
> in a way that helps the project forward in a clear direction. Pytest,
> Turbogears2, bootstrap were such items on the roadmap. I think it
> really helped to put focus.
>
The only reason I see for not mixing the issue tracker with suggestions is
the fact that bitbucket is really bad in separating bugs and 'suggestions'.
I don't see a reason why we shouldn't handle suggestions and bugs in one
tool, as long as it allows us to easily filter for either one of them. BTW
User will make suggestions via the issue tracker anyway. :-D


>
> >
> > I see multiple problems with this.
> > 1. it makes it really hard to get an overview of the open tasks
> > 2. it is impossible to search for particular tasks
> > 3. tasks in the wiki can't be discussed
> > 4. tasks in the wiki or the comments have no status
> > 5. bitbucket issue tracker doesn't allow to split issues into (sub-)tasks
> >
> > I'm open to what software to use, but I strongly believe we need to get
> > organized in this area.
> >
> > This is what I think the software should support.
> > 1. Creating filters to list certain kinds of issues
> > 2. Breakdown issues into (sub-)tasks
> > 3. Allow to distinguish between reported bugs and features/'user stories'
> >
>
> I don't know if it is needed to have such an advanced task management
> system for a project as small as Kallithea. I don't feel the need to
> split out issues into subtasks; it may be useful for large teams where
> different developers are working on such subtasks to cover one issue,
> but since at the moment typically only 1-3 people are working on a
> given issue, I think we can do with regular communication or comments
> on the issue.
> Being able to search issues based on keywords, and categorizing them,
> is of course basic stuff that is always useful.
>
> > My favorite issue tracker would be Jira, but since it is not open
> source, I
> > guess there are little changes that we'll use it. (even though the
> bitbucket
> > issue tracker is proprietary software as well :-/)
>
> I don't like bitbucket at all, to be honest. For one because it does
> not properly support mobile devices (I can't comment on commits from
> my phone).
>
> >
> > A quick web search lead me to taiga.io. I don't know if anybody already
> > knows it, but it seems it supports my requirements above and it is open
> > source. It also has a simple wiki which would allow as to completely get
> rid
> > of bitbucket. So we would be 100% open source.
>
> I don't have experience with it but I'm open to it.
>
> Regarding another point raised in the thread: I think that if we
> switch to something new, we should switch completely. Working with
> Bitbucket as well as something new, only means less organization than
> more. So IMO, we should migrate existing issues, the existing wiki
> info to the new thing. Repo hosting and PRs should move to our own
> Kallithea.
>
Agreed. But we need to learn more about taiga.io (or any other new tool)
before doing so. :-)
Therefore I'll start to use it for tracking my open task/issues etc. and
may mention the issues in my comments.

>
> Best regards,
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20161024/912476f9/attachment.html>