https://github.com/coala/gh-board/issues/1 is going to need to include configurability, so that repos with different structure can work in different ways. i.e. we need to at least support @philschatz 's label system and derived gh-board layout, and support what @ryanprior likes, and what @coala needs, so that our patches will be able to make it back through the forks to the main repo (c.f. https://github.com/coala/gh-board/issues/2 )
Including configuration in the master branch causes forks to diverge. We need to avoid that.
Some options for where to put the configuration:
the wiki
a different branch
an issue ;-)
Or, the configuration could be all derived from GitHub, if we ignore SAMPLE_REPOS. (and if we build a way to easily configure the front page, nobody will try to abuse this anyway.) It will increase build time to extract an ideal layout based on GitHub org/repo metadata. Also fetching the list of repos for an org requires an extra scope which orgs may not want in their Travis env vars, and if they use secure vars in the .travis.yml , their fork diverges.
https://github.com/coala/gh-board/issues/1 is going to need to include configurability, so that repos with different structure can work in different ways. i.e. we need to at least support @philschatz 's label system and derived gh-board layout, and support what @ryanprior likes, and what @coala needs, so that our patches will be able to make it back through the forks to the main repo (c.f. https://github.com/coala/gh-board/issues/2 )
There is one existing configuration item upstream, which is 'SAMPLE_REPOS' , and coala has added 'REPOSITORIES' for the pre-fetching. I am surprised that there are no forks which have modified this (c.f. https://github.com/coala/gh-board/issues/5), as that seems like a logical easy way to improve the front page (c.f. https://github.com/coala/gh-board/issues/3).
Including configuration in the master branch causes forks to diverge. We need to avoid that.
Some options for where to put the configuration:
Or, the configuration could be all derived from GitHub, if we ignore
SAMPLE_REPOS
. (and if we build a way to easily configure the front page, nobody will try to abuse this anyway.) It will increase build time to extract an ideal layout based on GitHub org/repo metadata. Also fetching the list of repos for an org requires an extra scope which orgs may not want in their Travis env vars, and if they use secure vars in the .travis.yml , their fork diverges.