Bonsai task management: GitHub Issues

[tmillross]

The various suggested Bonsai tasks are currently described primarily in the Wiki (plus here and here). The GitHub wiki interface is not designed for task management: it lacks discussion, deadlines, dependencies, workflows, task completion, archiving etc. So there is room for improvement here.
GitHub Issues are designed for this. @romainsacchi and I have discussed and researched this topic. We also considered GitHub project boards, but they mostly build upon and extend issues. We think that the tasks listed in the Wiki should be converted into Issues. This should make the Bonsai requirements, status, management, and development speed more visible, integrated and consistent, and help with decision making, provenance, and getting new users started with contributions.

Requirements:

• copy some example tasks from here
• create Bonsai-specific Labels for Issues
• communicate this suggestion to the mailing list

If general agreement on this approach is reached:

• copy across the remaining tasks from other locations
• delete the duplicated tasks from the Wiki
• update the getting started Wiki page to refer to high-priority tasks

Aside: I considered starting a BEP for this but thought the administrational overhead was too high. So I instead opted to make the changes as a proof-of-concept, then gather feedback after.

[romainsacchi]

I would like to suggest using the Projects features, since we have the Issues and Labels defined. I mean, have a look at it. I think it actually looks nice.

[romainsacchi]

As for the Milestones created, namely "pre-hackathon" and "alpha release", maybe they belong more to the Issues we would define within Hackathon repo, if we choose to do so there too. Because I was thinking that since the issues defined here are long-term tasks (as in "the tasks needed to have a working version of BONSAI"), the milestones should reflect a longer term vision of the development process. Or not?

[romainsacchi]

Maybe possible milestones could be the priority level of the tasks. In the Wiki, some tasks seem to be more urgent than others. Hence, filtering out priority-wise would give a good overview to the contributors as to where their help is needed first. What do you think?

However sadly, it is not possible to filter out tasks on display on the project board by milestones, only by labels and assignee.

Though I read here that using label to prioritize tasks is a work around. So I added priority labels and one can now filter out tasks on the project board display by priority level.

[tngTUDOR]

I also think that projects from github is better than filing issues.

[romainsacchi]

So, following Tom's third requirement, I suggest we communicate this idea of managing tasks to the mailing list to see if people like that, agree on labels, etc., and how it can be improved. What do you think ? @MicDr @tngTUDOR @cmutel @tmillross

[cmutel]

1. We shouldn't make a broader decision for the community, we should propose changes that can enhance people's experience, and indeed we have a formal structure for doing so :)

2. But the BEP process requires a testing phase, so please set something up. Just do it, it won't be perfect the first time in any case. I would not wait on the mailing list too much, as not everyone is as active as you are (sorry if this contradicts what I said before, but in this case we are talking about a trial phase, not the answer).

3. I think project boards (like https://github.com/orgs/BONSAMURAIS/projects/2) provide a great overview of how the overall project is progressing, and can be used in concert with issues quite nicely.

[MicDr]

Agree. No problem. In fact, in my view "Issues" are more related to issues of the defined Project's tasks rather than stand-alone objects.

[massimopizzol]

+1 for project boards, seems to me the most appropriate feature

[cmutel]

Two points that might help clarify things:

1. Most cards in the project board will refer to whole projects/working groups/long term efforts, and they will do their own task management. The overview/dashboard doesn't need to have details, but rather the general state of each project.

2. Let's think about how many cards we realistically want to show. I guess not more than 15. This already gives us some ideas of functionality we do or do not need.