Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Suggestion: Merge wiki and somewhere-safe in to somebody-should #496
Why do we have 3 separate github projects when one would do?
I suggest making somebody-should the primary repository:
This would get everything in one place and allow 2 repos to be nuked.
The somebody-should project could potentially be renamed as a second phase.
Doing the merge would be trivial in terms of moving the files - it can all be done via github desktop in a matter of minutes.
Likely pain points:
I'd have to suggest that "somebody-should" and "somewhere-safe" are semantically different, and should not be combined.
Somebody-should contains instructions of how to use the issue system that we're abusing for a public to-do list, along with it's main purpose of: using the issues.
Somewhere-safe is then a public repository of created items that have something to do with DoES; kind of like a shared folder, but with revision control and remote sync. It might have it's own issue related to the actual contents, which would be inappropriate to integrate into the somebody-should to-do list.
I can see an argument for integrating the wiki with somewhere-safe, as there's a cross over in their coverage — and assuming that the wiki repo is not being used for scripts or configuration to do with using/generating/updating the wiki — but is there a good reason for doing that?
@aubergine10 what name would you propose that would make the usage of the somebody-should repo clearer?
Maybe something like
However, that change would break loads of stuff - in particular all the #weeknotes - so definitely not possible this year, hence treating it as a potential second stage for future consideration.
I've not yet found any references to
Keeping stuff in one place = much easier to manage.
And, as most (all?) links to
The code repo in
Is the same true for
Suggested action plan:
In 2018, maybe discuss potential of merging
This feels a bit like doing something for the sake of doing something?
I'm not persuaded by the 'all in one place' suggestion. I'm also not seeing any ongoing difficulties in how it's currently structured that would require change? I'd don't have an issue with making that particular change, but havn't yet been persuaded there is a reason.
In terms of naming. Somebody should is a very obvious name as it says clearly what it is. Name on the tin. It also matches with the various other Somebody should groups out there. I'm not sure 'Issues' does the same thing, especially for those without a good awareness of Github, which will be a reasonable percentage of our new users. Are there alternatives that do the job better than the current?
It's doesn't feel like we're in a place yet to make unilateral changes or to act on an action plan. Patrick?
I'm also not convinced that moving everything into a single repo provides an obvious improvement — after all they are already in one location: github.com/DoESLiverpool!
And it also ties in nicely with an organisers only (private) repo called
I'd personally prefer that the wiki pages in the wiki repo were github pages, rather than a github wiki, because at least then we could make them look how we wanted, rather than having github branding all over everything; but I'm happy that direct editing in the wiki is easier for non-technical users.
I should also point out that all three repos in question are active and used frequently, so we should be very sure before monkeying around with them.
I understand that working through stuff as part of a community can be frustrating, not all of the time, but for everyone at least occasionally. Often talking about this stuff in person can make a difference, - I know that Patrick and I are always happy to do that.
For the wiki pages themselves, it's possible to create a custom sidebar that might clean up the layout marginally (certainly helps find key springboard pages such as Equipment, Rooms, etc). When used, it causes github to collapse the long scrolling pages list (and search box) in the sidebar - users can still expand it to get the full list & search, but hidden-by-default search box might cause pain.
For a much nicer view, we could potentially create a front-end site that renders the markdown as html with DoES navigation and branding. ESLint project is a good example of this - their code uses Node JS (IIRC) and is open source. They also use a markdown linter to preprocess the wiki content and ensue there's nothing nasty in there.
I've not personally used github.io, but have seen projects that do and it looks generally nice. Maybe there's some way to automate pulling content from wiki in to github pages? That way we retain easy editing in wiki, and updates are pushed to github pages for nicer view.