ScrumBut
ScrumBut copied to clipboard
jspahrsummers
Scrum, but with GitHub Issues (experimental)
We could write a backend with something like [servant](http://haskell-servant.github.io), then consume that API with a frontend server. This would have the nice benefit of _forcing_ us to create a great...
This was supposed to be implemented in https://github.com/jspahrsummers/ScrumBut/pull/22, but I missed it. :disappointed:
Right now, everything is hardcoded to GitHub.com.
Issue (and milestone?) bodies should be automatically rendered as Markdown, just like GitHub.
I'm not sure if it's a really short timeout, or some transient state that isn't getting persisted, but I feel like I have to log in most times I open...
For example, to get issues in a milestone currently requires that you have the _full_ repository and _full_ milestone models. We should instead allow lookups by short IDs (for example,...
This would be cool to have, but I don't yet know how we could make it fit an asynchronous workflow.
Using our [calculated velocity](https://github.com/jspahrsummers/ScrumBut/issues/13) and open milestones that have estimated issues, we should be able to predict how long it will take to reach any given point on the roadmap,...
When a milestone has at least one estimated issue, but they're not all estimated, we should show some kind of warning or indicator to highlight that. Otherwise, the [totals](https://github.com/jspahrsummers/ScrumBut/issues/12) could...