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

Figure out how to add work items more conveniently #1

Closed
ScalaWilliam opened this Issue Jul 15, 2017 · 6 comments

Comments

Projects
None yet
2 participants
@ScalaWilliam
Owner

ScalaWilliam commented Jul 15, 2017

Current UX:

Approach 1:

  1. Open terminal
  2. cd to the work dir
  3. type code .
  4. Create a new file in Code editor in _posts dir.
  5. Type in the metadata etc
  6. Commit & push

Approach 2:

  1. Open GitHub for Work
  2. Create new file in _posts dir
  3. Type in metadata etc
  4. Commit

Don't like either one because I have to enter the date manually, figure out the slug, and mess with Markdown.

One approach is:
Post an issue in a GitHub repo (like Codemill) & it automatically gets pushed to here. Downside is it's a silo and I don't want to depend on github forever.

Would be much nicer to do POSSE to Work & get GH Issues created from that automatically. However I'm not sure two-way sync for this exists just yet :-(.

Another is to not automate the issue linking part since my pain point is just creating that file. I would not mind a separate custom UI with price fields etc although that's a tad bothersome to do.

For the best suggestion I will pay $10.00.
Update: for the suggestion I use, I'll pay $10.00
Cross posted: http://work.scalawilliam.com/convenient-work-items-add/

ScalaWilliam added a commit that referenced this issue Jul 15, 2017

Rename 2017-07-15-convenient-work-items-add to 2017-07-15-convenient-…
…work-items-add.md

BAH.... Ironically for #1 - this is exactly why I need some improvements.
@miklb

This comment has been minimized.

Show comment
Hide comment
@miklb

miklb Jul 15, 2017

I had a TextExpander snippet that I used to create the yaml front matter, including slugifying the title for me.

There is also Jekyll Admin a GUI for creating the front matter that I believe will help with date and slug.

As to automating with the GH issue, that's a whole ball of wax.

miklb commented Jul 15, 2017

I had a TextExpander snippet that I used to create the yaml front matter, including slugifying the title for me.

There is also Jekyll Admin a GUI for creating the front matter that I believe will help with date and slug.

As to automating with the GH issue, that's a whole ball of wax.

@miklb

This comment has been minimized.

Show comment
Hide comment
@miklb

miklb Jul 16, 2017

I mentioned this is IRC but silo.pub has support for creating GH issues, might be able to use micropub to create an issue while creating the entry https://silo.pub/developers#vocab-github

miklb commented Jul 16, 2017

I mentioned this is IRC but silo.pub has support for creating GH issues, might be able to use micropub to create an issue while creating the entry https://silo.pub/developers#vocab-github

@ScalaWilliam

This comment has been minimized.

Show comment
Hide comment
@ScalaWilliam

ScalaWilliam Jul 16, 2017

Owner

That is quite cool. Is it possible to cross link the issue with the original content?
Looks like my requirement was not defined well enough. Actually after posting the work item on the site I would add its URL on the github issue.

This would help retain the context wherever you are.

Owner

ScalaWilliam commented Jul 16, 2017

That is quite cool. Is it possible to cross link the issue with the original content?
Looks like my requirement was not defined well enough. Actually after posting the work item on the site I would add its URL on the github issue.

This would help retain the context wherever you are.

@miklb

This comment has been minimized.

Show comment
Hide comment
@miklb

miklb Jul 16, 2017

In theory, there should be a way to pass the created URL from the micropub client and pass that in the content for the issue when creating it. Likewise, I'm assuming at this point the json response from silo.pub would contain the issue # and URL that could be passed back as yaml front matter that could be read in the jekyll templates.

There is a Jekyll micropub endpoint that you could probably adapt for the specialized yaml.

The trick would be configuring the silo.pub endpoint as a syndicate-to target for micropub. I'm actually trying to figure that out now for a different reason.

Only other way I'd think about automating would be to just use the GitHub API in a rake task or plugin, but to host it on GitHub you'd have to use something like Travis CI or Circle CI to run a plugin/rake task and push back to GitHub. I did that for sending webmentions and getting back the json response which I stored as a _data file to be able to use in my Liquid templates.

miklb commented Jul 16, 2017

In theory, there should be a way to pass the created URL from the micropub client and pass that in the content for the issue when creating it. Likewise, I'm assuming at this point the json response from silo.pub would contain the issue # and URL that could be passed back as yaml front matter that could be read in the jekyll templates.

There is a Jekyll micropub endpoint that you could probably adapt for the specialized yaml.

The trick would be configuring the silo.pub endpoint as a syndicate-to target for micropub. I'm actually trying to figure that out now for a different reason.

Only other way I'd think about automating would be to just use the GitHub API in a rake task or plugin, but to host it on GitHub you'd have to use something like Travis CI or Circle CI to run a plugin/rake task and push back to GitHub. I did that for sending webmentions and getting back the json response which I stored as a _data file to be able to use in my Liquid templates.

@ScalaWilliam

This comment has been minimized.

Show comment
Hide comment
@ScalaWilliam

ScalaWilliam Jul 17, 2017

Owner

Thanks for the input.

I'm thinking that it'll be hard to improve on GitHub's UX without significant investment. I would like it in the log run, but in the short term need a solution as well.

So begin with PESOS, move towards POSSE.

PESOS approach: "GitHub Issues (silo) --> create & update this repository". Can be done with a WebHook. When receiving a new GitHub issue notification, look for posts in the repository that match the issue URL. Then there are two options: found; not found.
When found, we do an idempotent push.
When not found, create a slug & also update the original issue to include the slug via GitHub API.

Should be able to create a specification & issue for somebody to implement this; and then refactor until we get to POSSE.

POSSE/long term approach:

  • Micropub to jekyll as you suggested
  • two-way sync with GitHub
  • Or even eliminate github completely

How does this sound?

Owner

ScalaWilliam commented Jul 17, 2017

Thanks for the input.

I'm thinking that it'll be hard to improve on GitHub's UX without significant investment. I would like it in the log run, but in the short term need a solution as well.

So begin with PESOS, move towards POSSE.

PESOS approach: "GitHub Issues (silo) --> create & update this repository". Can be done with a WebHook. When receiving a new GitHub issue notification, look for posts in the repository that match the issue URL. Then there are two options: found; not found.
When found, we do an idempotent push.
When not found, create a slug & also update the original issue to include the slug via GitHub API.

Should be able to create a specification & issue for somebody to implement this; and then refactor until we get to POSSE.

POSSE/long term approach:

  • Micropub to jekyll as you suggested
  • two-way sync with GitHub
  • Or even eliminate github completely

How does this sound?

@ScalaWilliam

This comment has been minimized.

Show comment
Hide comment
@ScalaWilliam

ScalaWilliam Jul 30, 2017

Owner

I decided it'll be better to optimise the whole workflow instead, based on feedback from people who worked here.

Owner

ScalaWilliam commented Jul 30, 2017

I decided it'll be better to optimise the whole workflow instead, based on feedback from people who worked here.

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