Figure out how to add work items more conveniently

[ScalaWilliam]

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/

[miklb]

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]

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]

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]

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]

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]

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