issue

 issue  is a special kind of article post that is a reply to typically some source code, though potentially anything at a source control repository.

Why
You should post issues on your own site first because GitHub goes down sometimes for various reasons. And then POSSE to GitHub.

How
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 publish
Here is a minimal issue post:

Regarding Example App: Please add support for microformats It would be great if Example App supported microformats!

Issue posts are typically an article with an in-reply-to URL of the issues page you are posting to. For example, on Github the Bridgy issues page is https://github.com/snarfed/bridgy/issues.

See examples below for more details.

How to with Known
See and use: https://github.com/mapkyca/KnownGithub

POSSE
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)
 * does this
 * Automatically using the Bridgy service
 * About Bridgy: How do I create a GitHub issue or comment?
 * undefined does this, see examples below.
 * Automatically using silo.pub software on your own server
 * does this.

Other POSSE destinations
See and add to for how POSSEing to other destinations (e.g. Bugzilla) could work.

Aaron Parecki
occasionally posts issues on aaronparecki.com syndicated to GitHub.com
 * https://aaronparecki.com/2016/05/28/6/push
 * https://aaronparecki.com/2015/11/04/6/
 * https://aaronparecki.com/2015/02/27/18/superfeedr
 * https://aaronparecki.com/2015/02/13/11/
 * https://aaronparecki.com/2013/09/24/8/checkie
 * https://aaronparecki.com/2013/09/02/6/idno

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, 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.

Tantek
undefined has started posting issues to his own site since 2018-02-21
 * http://tantek.com/2018/052/b1/bridgy-github-support-images-hyperlinks
 * GitHub POSSE copy: https://github.com/snarfed/bridgy/issues/794
 * issues are
 * articles with
 * in-reply-to set to the project's GitHub repo URL
 * name for the issue name
 * content for the contents of the issue
 * not POSSEd to Twitter

gRegor Morrill
started occasionally posting issues on his site 2021-10-21

POSSE to Github using Bridgy:
 * https://gregorlove.com/2021/10/check-meta-headers-for-http-status/
 * https://github.com/gRegorLove/ProcessWire-Webmention/issues/25

indie site to indie site:
 * Sent via webmention to 's code repository for indieweb.rocks
 * https://gregorlove.com/2022/08/indieweb-rocks-issues/
 * https://ragt.ag/code/indieweb.rocks

GitHub
GitHub allows posting of issues as part of their issue tracker feature for each repo.

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:
 * : bridgy: No webmentions to original URLs that include emojis
 * : indigenous-ios: Add the ability to temporarily hide a channel

Still TBD:
 * receive and display reacji
 * BONUS: receive and display Salmentions for reacji on comments on your issue!

Complete comment solution
Similarly, lots of indieweb folks post reply post and display subsequent comments (and sometimes reacji too).

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

Special Responses
GitHub allows a set of special responses to issues, which alter the issue state in various ways: Only some people (the issue "creator"? the repo "owner"?) can take some/most of these actions.
 * close (see below for some previous exploration of details)
 * re-open
 * lock (see below for some previous exploration of details)
 * unlock

Nonetheless we should model these special responses so we can own these interactions on our own sites as well (and not have to use the GitHub UI to do so).

This requires exploring at least:
 * 1) . How does the GitHub API represent and support these special responses?
 * 2) . Do other issues/ticketing systems (Bugzilla? Trac? Jira?) support these special responses or others, and how can we model them as a set? (perhaps similar to how we modeled special RSVP responses to events, by studying event hosting services and systems).

Issues / feature requests for Bridgy:
 * Publish to GitHub to at least explore the feasibility of (1), upon which we can further explore (2) with other systems
 * https://github.com/snarfed/bridgy/issues/915
 * Backfeed from GitHub for closing, re-opening, locking, unlocking issues:
 * https://github.com/snarfed/bridgy/issues/833

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?

Alternatively, we could model closing/re-opening as a separate response (with a new property), and then allow for it to be combined with a normal reply.

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.

Some discussion:
 * 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. -
 * 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. - undefined
 * 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:
 * "Closing issue." at end of reply content (if you know you can do so). E.g.:
 * https://tantek.com/2018/185/t4/ and on GitHub
 * https://tantek.com/2020/042/t2/ and on GitHub
 * "Issue may be closed."
 * "Please close this issue."

Re-opening:
 * "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?

2022-03-18: This could be a good application of changing the audience of the issue

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.