GitHub Workflow

In accordance with this thread (Release 0.4.0 Thread), the plan is to use GitHub to organize our workflow towards the next update. There are a few important links to anyone interested:

The main list of issues:

Issues assigned to the upcoming release (0.4.0):

A neat dashboard for an alternative view of what to work on for the next release:

So a two things I’d suggest we work on:

  • Create issues for all the features planned for the upcoming release
  • Discard/archive duplicate or irrelevant issues

There are probably still some unfinished issues marked for 0.3.4. They should be moved to the 0.4.0 milestone

1 Like

After skimming over the features available on GitHub, it looks perfect for being used to track our progress. We can create teams, create different repositories (repos) for different types of work, assign different teams to different repos, and create issues for each specific task we need done within each repo and assign people to work on them. I will work on this over the next few days to create something for us and post my results (and also explain how to use it and what all these different terms mean for those not familiar with GitHub).

Also, while talking with Oliveriver, I realized that the different web presences we have for development fit into a perfect hierarchy of workflow.

  1. Forum. We create and discuss new ideas on the forum. This could be something dev related, like “We need to replace the nuclei with disco balls”, or it could be something organization related, like “We need to update the wiki page on the Microbe Editor.” Sometimes though, ideas are obvious (like bugfixes) in which case we can skip this step.
  2. GitHub. When we complete the discussion for a game feature or wiki change or something on the forums, we then create an issue on GitHub to track that task we want done. We can assign it to a person, give it tags to categorize it, assign it to a release version, link the forum discussion that spawned the idea, etc. Using the above example, we’d create an issue called “Replace nuclei with disco balls” or “Update wiki page on Microbe Editor”.
  3. Wiki. Once an issue is complete, we create or update a wiki page for it if necessary. Using the above examples, in the first case we’d update the page on Organelles (or whichever page it is) and change all references of nucleus to disco ball. In the second case we wouldn’t need to add or update a wiki page because the issue literally was to update a wiki page.

Slack then fills in the gaps between all these steps by being a quick and easy communication platform for questions like “Hey can you give me access to our Twitter page?”.

Obviously different situations will need different workflows, but I think we should try to stick to this for as many tasks as possible for the best results.


I agree. But I want to add that for bugs and other “obvious things” that don’t need discussing beforehand, they could be directly opened on github. Also if some potential developer / player finds a bug they can also open github issues.

But for topics that need discussing it is a good idea to first hash out the ideas on these forums, or maybe even on the community forums to keep them going…

Yeah that’s true, depending on the task we could even bring the discussion to the community forum.

I’m all for this approach provided everybody can be trusted to post publicly instead of using Slack. I know it’s not as convenient, but it creates a public and permanent record of conversations which can serve us by keeping discussions around for future reference and serve the fans by generating more visible activity. If this is the way to do things that allows that change, so be it.

1 Like

Isn’t this forum (discourse software) almost as convenient as new messages are shown without reloading the page so it is almost instant messaging

That was part of the rationale behind choosing it - we hoped it would make the forum nicer to use so people would use it more.