New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

better platform #53

Closed
stevekrouse opened this Issue Oct 4, 2017 · 4 comments

Comments

Projects
None yet
1 participant
@stevekrouse
Owner

stevekrouse commented Oct 4, 2017

So that it's not as hard to iterate on the structure of the site without breaking old links...

@stevekrouse stevekrouse added the priority label Oct 4, 2017

@stevekrouse stevekrouse changed the title from more historically preserving platform to better platform Oct 5, 2017

@stevekrouse

This comment has been minimized.

Show comment
Hide comment
@stevekrouse

stevekrouse Oct 5, 2017

Owner

Criteria:

  1. Don't break old links (include the current mapping from name to id or content in all links)
  2. Keep a history of changes (preferably with meta data)
  3. Be able to refer to things by their identity and content (not by their mutable location or name)

Identity

Identity is tricky. Is a person the collection of atoms that make them up - their content? Or their name? Or where they live? Depending on the situation, we might want to refer to a person by each of these. Sometimes I want to link to content by it's name (or ID) so that if I update the content at that ID, you get the most updated version.

However, I also want you to be able to see the version of the content that was there at the time of the link, not the newer version. It's almost like I need both links: click here for the most recent version of this content, and click here for the version of this content we linked to. Another way to do this is to always link to the old version of the content and then when you're at that page have a notice on the page saying "this is old content. a newer version is available here"

Git commit hashes

What's neat about git is that it gives me a very easy way to link to any historical version of any piece of content. There are problems with this:

  1. I would be constantly be sending people to rawgit because there's no way (that I know of yet) to link to commit hashes on a github pages site... However even as I write this I realize that I could probably write some front-end code (potentially with a backend Clay service) that could pull the commit hash and display it...

  2. I would also need client-side code to insert the current commit hash into every URL of the site so that when people link to things, they also are pulling the unbreakable link.

  3. It's easy to allow people to see the more updated versions of the page that they're on, but what if I move the content to another page on the site? It's be great if I could somehow track that information in machine-readable meta-data but I think for now the best I have is a human-readable commit message explaining that the content was moved so that a user can follow the breadcrumb trail if they want to.

IDs and Github Issues

For years now, I've loved using Github issues for a variety of things. They are just so damned powerful because:

  1. They each are associated with a unique ID that never changes despite name changes.
  2. They are markdown enabled.
  3. They can accept as many comments from as many logged in users as you want.
  4. They easily link to other issues and code.
  5. Anyone you allow can create new ones.

(And there are a lot of other features that make them good as a ticketing system for code but that's besides the point in this discussion.)

On the downside, they don't have an amazing historical record if someone edits a comment.

But basically they are a database/website/commenting platform and it's great. I would love to have some of these features in my website, particularly:

  1. Allowing comments #50 (which can be enabled pretty easily through a platform)
  2. Allowing users to add content (which is pretty straight-forward with pull requests, but I can definitely make this easier with an edit button #28 or fork me on github banner #6)

Wiki

Another idea is that wiki software, potentially like tiddlywiki, could be a good platform for this project. On the one hand, this is the website for my research project, my thoughts, my prototypes.

On the other hand, I don't need ownership over these ideas. If I created a wikipedia page for StreamSheets and others added thoughts or content to the page, that'd be amazing - assuming the content was good of course, but that's a solvable problem in theory. A lot of us are duplicating efforts here and it'd be neat if there was a single repository of this information that we could all contribute to...

Ok, I feel like my github issues are getting a little out of hand. I'm going to organize them a bit...

Owner

stevekrouse commented Oct 5, 2017

Criteria:

  1. Don't break old links (include the current mapping from name to id or content in all links)
  2. Keep a history of changes (preferably with meta data)
  3. Be able to refer to things by their identity and content (not by their mutable location or name)

Identity

Identity is tricky. Is a person the collection of atoms that make them up - their content? Or their name? Or where they live? Depending on the situation, we might want to refer to a person by each of these. Sometimes I want to link to content by it's name (or ID) so that if I update the content at that ID, you get the most updated version.

However, I also want you to be able to see the version of the content that was there at the time of the link, not the newer version. It's almost like I need both links: click here for the most recent version of this content, and click here for the version of this content we linked to. Another way to do this is to always link to the old version of the content and then when you're at that page have a notice on the page saying "this is old content. a newer version is available here"

Git commit hashes

What's neat about git is that it gives me a very easy way to link to any historical version of any piece of content. There are problems with this:

  1. I would be constantly be sending people to rawgit because there's no way (that I know of yet) to link to commit hashes on a github pages site... However even as I write this I realize that I could probably write some front-end code (potentially with a backend Clay service) that could pull the commit hash and display it...

  2. I would also need client-side code to insert the current commit hash into every URL of the site so that when people link to things, they also are pulling the unbreakable link.

  3. It's easy to allow people to see the more updated versions of the page that they're on, but what if I move the content to another page on the site? It's be great if I could somehow track that information in machine-readable meta-data but I think for now the best I have is a human-readable commit message explaining that the content was moved so that a user can follow the breadcrumb trail if they want to.

IDs and Github Issues

For years now, I've loved using Github issues for a variety of things. They are just so damned powerful because:

  1. They each are associated with a unique ID that never changes despite name changes.
  2. They are markdown enabled.
  3. They can accept as many comments from as many logged in users as you want.
  4. They easily link to other issues and code.
  5. Anyone you allow can create new ones.

(And there are a lot of other features that make them good as a ticketing system for code but that's besides the point in this discussion.)

On the downside, they don't have an amazing historical record if someone edits a comment.

But basically they are a database/website/commenting platform and it's great. I would love to have some of these features in my website, particularly:

  1. Allowing comments #50 (which can be enabled pretty easily through a platform)
  2. Allowing users to add content (which is pretty straight-forward with pull requests, but I can definitely make this easier with an edit button #28 or fork me on github banner #6)

Wiki

Another idea is that wiki software, potentially like tiddlywiki, could be a good platform for this project. On the one hand, this is the website for my research project, my thoughts, my prototypes.

On the other hand, I don't need ownership over these ideas. If I created a wikipedia page for StreamSheets and others added thoughts or content to the page, that'd be amazing - assuming the content was good of course, but that's a solvable problem in theory. A lot of us are duplicating efforts here and it'd be neat if there was a single repository of this information that we could all contribute to...

Ok, I feel like my github issues are getting a little out of hand. I'm going to organize them a bit...

@stevekrouse

This comment has been minimized.

Show comment
Hide comment
@stevekrouse

stevekrouse Oct 6, 2017

Owner

The ideas I have about moving forward here are pretty thoroughly thought out here on #51

Owner

stevekrouse commented Oct 6, 2017

The ideas I have about moving forward here are pretty thoroughly thought out here on #51

stevekrouse added a commit that referenced this issue Oct 6, 2017

Continued developing master plan
I've been making a lot of progress in the past few days, thinking about this project at a high level. I made a lot of progress in the shower this morning:

![image](https://user-images.githubusercontent.com/2288939/31288236-13809c5e-aa92-11e7-8ba7-7dadee620891.png)

There are a few next steps:

1. Articulate my prototype ideas for StreamSheets, Scratch or WoofJS FRP (and come up with a name for this), generic GUI for langauges, and more if I have them.

#54
#55

2. Spell out my design principles.

#9

3. Send my master plan around to friends.

4. Consider the future organization of the website and if now's a good time to go for it. #53
@stevekrouse

This comment has been minimized.

Show comment
Hide comment
@stevekrouse

stevekrouse Oct 6, 2017

Owner

There's a part of me that loves this commit message and how it elegantly replaces /journal 16321d6

However part of me does not like editing my commit message in nano and not being able to preview it in markdown... Problem mostly solved: git config --global core.editor "c9 open --wait"

The only remaining problem is that there's no super easy way to get a live markdown preview...

Owner

stevekrouse commented Oct 6, 2017

There's a part of me that loves this commit message and how it elegantly replaces /journal 16321d6

However part of me does not like editing my commit message in nano and not being able to preview it in markdown... Problem mostly solved: git config --global core.editor "c9 open --wait"

The only remaining problem is that there's no super easy way to get a live markdown preview...

@stevekrouse

This comment has been minimized.

Show comment
Hide comment
@stevekrouse

stevekrouse Oct 8, 2017

Owner

Closed for now... Going to work on unbreakable-links here: https://github.com/stevekrouse/unbreakable-links

Owner

stevekrouse commented Oct 8, 2017

Closed for now... Going to work on unbreakable-links here: https://github.com/stevekrouse/unbreakable-links

@stevekrouse stevekrouse closed this Oct 8, 2017

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