This section needs expansion! As you implement, try to add tips here for what worked for you!
In general: analyze the IndieWeb Examples below and document some brainstorming!
How to post
How to with WordPress
How to with Known
See and use: https://github.com/mapkyca/KnownGithub
- 1 Why
- 2 How
- 3 IndieWeb Examples
- 4 Silo Examples
- 5 Brainstorming
- 6 See Also
You can POSSE issue posts to the issues collections of their respective projects.
POSSE to GitHub
You can POSSE to GitHub:
- Manually (a few indieweb folks have done this)
- Automatically by posting with WordPress and Known using their respective plugins (see above)
- Chris Aldrich does this
- Automatically using the Bridgy service
- About Bridgy: How do I create a GitHub issue or comment?
- Tantek Çelik does this, see examples below.
- Automatically using silo.pub software on your own server
- Aaron Parecki does this.
Other POSSE destinations
See and add to #Brainstorming for how POSSEing to other destinations (e.g. Bugzilla) could work.
Aaron Parecki occasionally posts issues on aaronparecki.com syndicated to GitHub.com
- Chris Aldrich often posts issues to his own website as simple notes (or replies to issues as simple replies) and automatically POSSEs them to GitHub repos using the Github plugin for Known.
- On 2018-02-28, Chris Aldrich used the functionality provided by the Bridgy Publish plugin for WordPress to use Bridgy to POSSE a reply to a GitHub issue from his own site. He received his first backfed reply from GitHub via bridgy on 2018-03-02.
- Now that Post Kinds Plugin supports issue posts, he'll begin publishing those via POSSE from his primary WordPress website as well. He published his first official issue via POSSE on his primary site on 2018-03-02. A feed of all his issues can be found at http://boffosocko.com/kind/issue/ Documentation for some of this set up with WordPress can be found at Enabling two way communication with WordPress and GitHub for issues.
Complete POSSE backfeed solution
We have community members with complete POSSE + backfeed solution for issue posts, and responses thereto with Bridgy. If there are any comprehensive descriptions or instructions for how to do this, please add them here!
Complete issue solution
Here are examples of POSSEd issues, some with backfed comments:
- Chris Aldrich: bridgy: No webmentions to original URLs that include emojis
- Eddie Hinkle: indigenous-ios: Add the ability to temporarily hide a channel
- receive and display reacji
- BONUS: receive and display Salmentions for reacji on comments on your issue!
Complete comment solution
For the purposes of an "issue", what is perhaps special is the added expectation that a comment on an issue typically makes very little (if any) sense without the full context of the original issue and any comments that were made before your comment. Thus it would be great to see an example of:
- post a reply to an issue
- display full reply-context of your reply, including any previous comments, and original issue at the top
- receive and display subsequent comments
- receive and display reacji on your reply
- BONUS: receive and display Salmentions for reacji on
- subsequent comments
- prior comments
- original issue
Close and re-open issues when commenting
GitHub allows commenters (with authorization) to close / re-open an issue at the same time as submitting a comment.
How should we model this?
Do we need an additional property for a reply to indicate that it closes/re-opens the thing it is a reply to?
Should we consider other systems like Bugzilla or other traditional bug-tracking solutions?
Like "Resolve" an issue with a specific state? Or should that be a separate response since it is something you do separately from commenting.
- This is a UI shortcut that creates two separate user-visible events ("posts") on the issue timeline, not a single combined event. Example. The API also distinguishes events and comments, with no object for a combined-comment and-close/reopen. - Ryan Barrett
- Arguing from the perspective of API sounds like a plumbing-centric approach. I’d say the opposite is true - the UI "shortcut" is representative of the user intent, which is the "actual" aspect of reality we want to model, not whatever happens to be exposed in storage or API. - Tantek Çelik
- Similar example: Gmail Send + Archive. Except in that case Gmail's UI clearly treats it as an atomic transaction set of actions since if you "Undo" it undoes send+archive.
Plain text close re-open
Perhaps for now we can come up with plain text to communicate the intent of "closing" an issue or "re-opening it".
- "Closing issue." at end of reply content (if you know you can do so)
- "Issue may be closed."
- "Please close this issue."
- "Re-opening issue." at end of reply content (if you know you can do so)
- "Please re-open issue."
- ... other thoughts?
Lock and unlock issues
GitHub allows someone with authorization to lock / unlock an issue, which blocks comments from unauthorized commenters.
How or should we model this?
Do we need to create a new type of response?
POSSE to Bugzilla
Bugzilla has many fields, and it's not clear how to represent them all in such a way that they could be automatically POSSEd.
Complete Federated Webmention solution
This is just brainstorming for now - at a high level
- own your own repos
- allow federated issues on your repos (receive, display, update, delete etc.)
- allow federated responses (comments, reacji) on those issues
Everything peer to peer, no need for any central location to POSSE to / backfeed from.
As far as we know, NO ONE (using any technology / standards) has this working, anywhere.
By exploring the space with POSSE + backfeed as described previously, it is likely we can figure out how to do all this via Webmention.