Suggestion: Merge wiki and somewhere-safe in to somebody-should #496

Closed
aubergine10 opened this Issue May 7, 2017 · 8 comments

Comments

@aubergine10
Contributor

aubergine10 commented May 7, 2017

Why do we have 3 separate github projects when one would do?

I suggest making somebody-should the primary repository:

  • wiki/wiki -> somebody-should/wiki
  • somewhere-safe (code tab) -> somebody-should (code tab)

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:

  • Some stuff on the website points to wiki and will need updating - would tie in to planned website update
  • Quite a few links in wiki to somewhere-safe - easy to find by downloading wiki (git cmd line or git desktop) then doing search and replace across files (eg. in Sublime Text 3)
  • Linking between pages in wiki might break in some places, easy - if a little time-consuming - to fix.
  • Links from outside world would break - any idea how many there might be?
@DefProc

This comment has been minimized.

Show comment
Hide comment
@DefProc

DefProc May 7, 2017

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?

DefProc commented May 7, 2017

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?

@aubergine10

This comment has been minimized.

Show comment
Hide comment
@aubergine10

aubergine10 May 7, 2017

Contributor

what name would you propose that would make the usage of the somebody-should repo clearer?

Maybe something like public, so the URLs would become:

  • github.com/DoESLiverpool/public/
  • github.com/DoESLiverpool/public/wiki
  • github.com/DoESLiverpool/public/issues

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 can see an argument for integrating the wiki with somewhere-safe, as there's a cross over in their coverage

I've not yet found any references to somewhere-safe outside of the wiki. It seems logical to merge those two repos at the very least.

but is there a good reason for doing that?

Keeping stuff in one place = much easier to manage.

And, as most (all?) links to somewhere-safe originate in wiki, it would make navigating back to wiki significantly easier - just click the Wiki tab at top of screen.

Additionally, the wiki is far more publicised than somewhere-safe - so moving somewhere-safe in to wiki will make those files much more discoverable, which in turn will make it much more obvious where those types of files should be stored.

and assuming that the wiki repo is not being used for scripts or configuration to do with using/generating/updating the wiki

The code repo in wiki (separate to the wiki repo in wiki) is not currently used other than a README. Code for things like doorbots, etc., always ends up in separate repos anyway, so I don't see any conflicts either now or in the future in this respect.

I've checked somebody-should and the only bit of that repo that's used is the code section. There's no wiki or issues.

I'd have to suggest that "somebody-should" and "somewhere-safe" are semantically different, and should not be combined.

Is the same true for wiki and somebody-should? For example, the wiki documents all the equipment, groups, etc - all stuff that is issue tracked via somebody-should.

Suggested action plan:

Phase 1:

  • Guy (@aubergine10) moves somewhere-safe code repo in to wiki code repo.
  • Guy edits somewhere-safe/README.md to direct people to wiki
  • In July 2017, Guy deletes somewhere-safe repo

Phase 2:

In 2018, maybe discuss potential of merging wiki and somebody-should as separate issue ticket.

Contributor

aubergine10 commented May 7, 2017

what name would you propose that would make the usage of the somebody-should repo clearer?

Maybe something like public, so the URLs would become:

  • github.com/DoESLiverpool/public/
  • github.com/DoESLiverpool/public/wiki
  • github.com/DoESLiverpool/public/issues

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 can see an argument for integrating the wiki with somewhere-safe, as there's a cross over in their coverage

I've not yet found any references to somewhere-safe outside of the wiki. It seems logical to merge those two repos at the very least.

but is there a good reason for doing that?

Keeping stuff in one place = much easier to manage.

And, as most (all?) links to somewhere-safe originate in wiki, it would make navigating back to wiki significantly easier - just click the Wiki tab at top of screen.

Additionally, the wiki is far more publicised than somewhere-safe - so moving somewhere-safe in to wiki will make those files much more discoverable, which in turn will make it much more obvious where those types of files should be stored.

and assuming that the wiki repo is not being used for scripts or configuration to do with using/generating/updating the wiki

The code repo in wiki (separate to the wiki repo in wiki) is not currently used other than a README. Code for things like doorbots, etc., always ends up in separate repos anyway, so I don't see any conflicts either now or in the future in this respect.

I've checked somebody-should and the only bit of that repo that's used is the code section. There's no wiki or issues.

I'd have to suggest that "somebody-should" and "somewhere-safe" are semantically different, and should not be combined.

Is the same true for wiki and somebody-should? For example, the wiki documents all the equipment, groups, etc - all stuff that is issue tracked via somebody-should.

Suggested action plan:

Phase 1:

  • Guy (@aubergine10) moves somewhere-safe code repo in to wiki code repo.
  • Guy edits somewhere-safe/README.md to direct people to wiki
  • In July 2017, Guy deletes somewhere-safe repo

Phase 2:

In 2018, maybe discuss potential of merging wiki and somebody-should as separate issue ticket.

@stevesparrow

This comment has been minimized.

Show comment
Hide comment
@stevesparrow

stevesparrow May 7, 2017

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?

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?

@DefProc

This comment has been minimized.

Show comment
Hide comment
@DefProc

DefProc May 7, 2017

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!

The names somebody-should and somewhere-safe come from IRL interactions that happen in DoES. When anyone suggests that, "somebody should… <insert great improvement for DoES>", there is now a clear action which that person can take, ie. "put it on the somebody-should list". Similarly, when somebody has created something that relates to DoES (e.g. an improved laser cutter ruler for Gerald) and ask where they should put the file so it can be found next time, they can be told to, "put it in somewhere-safe".

And it also ties in nicely with an organisers only (private) repo called somewhere-really-safe.

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.

DefProc commented May 7, 2017

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!

The names somebody-should and somewhere-safe come from IRL interactions that happen in DoES. When anyone suggests that, "somebody should… <insert great improvement for DoES>", there is now a clear action which that person can take, ie. "put it on the somebody-should list". Similarly, when somebody has created something that relates to DoES (e.g. an improved laser cutter ruler for Gerald) and ask where they should put the file so it can be found next time, they can be told to, "put it in somewhere-safe".

And it also ties in nicely with an organisers only (private) repo called somewhere-really-safe.

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.

@aubergine10

This comment has been minimized.

Show comment
Hide comment
@aubergine10

aubergine10 May 7, 2017

Contributor

meh.

Contributor

aubergine10 commented May 7, 2017

meh.

@aubergine10 aubergine10 closed this May 7, 2017

@stevesparrow stevesparrow reopened this May 7, 2017

@stevesparrow

This comment has been minimized.

Show comment
Hide comment
@stevesparrow

stevesparrow May 7, 2017

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.

Cheers
Steve

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.

Cheers
Steve

@aubergine10

This comment has been minimized.

Show comment
Hide comment
@aubergine10

aubergine10 May 7, 2017

Contributor

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.

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.

Contributor

aubergine10 commented May 7, 2017

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.

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.

@stevesparrow

This comment has been minimized.

Show comment
Hide comment
@stevesparrow

stevesparrow Jul 21, 2017

@aubergine10 want to do anything more with this?

Sent from my Asus P027 using FastHub

@aubergine10 want to do anything more with this?

Sent from my Asus P027 using FastHub

@DoESsean DoESsean closed this Dec 14, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment