View source for issue

{{emojicon|🐛}}
[[Category:PostType]]
{{stub}}

    '''<dfn>issue</dfn>''' 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:

<pre>
<div class="h-entry">
  <a class="u-in-reply-to" href="https://example.com/issues">Regarding Example App:</a>
  <h1 class="p-name">Please add support for microformats</h1>
  <p class="e-content">It would be great if Example App supported microformats!</p>
</div>
</pre>

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 WordPress ===
* {{citation
| title = Enabling two way communication with WordPress and GitHub for Issues
| url = https://boffosocko.com/2018/03/03/enabling-two-way-communication-with-wordpress-and-github-for-issues/
| author = {{chrisaldrich}}
| published = 2018-03-03
| archiveurl = http://web.archive.org/web/20220924203458/https://boffosocko.com/2018/03/03/enabling-two-way-communication-with-wordpress-and-github-for-issues/
}}

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

__TOC__
=== 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)
** {{chrisaldrich}} does this
* Automatically using the [[Bridgy]] service
** [https://brid.gy/about#github-issue-comment About Bridgy: How do I create a GitHub issue or comment?]
** {{t}} does this, see examples below.
* Automatically using [[silo.pub]] software on your own server
** {{aaronpk}} does this.
==== Other POSSE destinations ====
See and add to [[#Brainstorming]] for how POSSEing to other destinations (e.g. Bugzilla) could work.

== IndieWeb Examples ==
=== Aaron Parecki ===
{{aaronpk}} 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 ===
* {{chrisaldrich}} often posts issues to his own [http://stream.boffosocko.com/content/all/?q=github website] as simple [[note|notes]] (or replies to issues as simple [[reply|replies]]) and automatically POSSEs them to GitHub repos using the [https://github.com/mapkyca/KnownGithub Github plugin] for [[Known]].
* On [http://boffosocko.com/2018/02/28/first-reply-to-github-with-bridgy-publish/ 2018-02-28], {{chrisaldrich}} used the functionality provided by the [[Bridgy Publish plugin]] for WordPress to use [[Bridgy]] to [[POSSE]] a [[reply]] to a [https://github.com/dshanske/bridgy-publish/issues/56#issuecomment-369372604 GitHub issue] from his own site. He received his first [[backfeed|backfed]] reply from GitHub via [[bridgy]] on [http://boffosocko.com/2018/02/28/first-reply-to-github-with-bridgy-publish/#comment-47091 2018-03-02].
* Now that [[Post Kinds Plugin]] supports [[issues|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 [http://boffosocko.com/2018/03/02/support-for-acquisition-kind/ 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 [http://boffosocko.com/2018/03/03/enabling-two-way-communication-with-wordpress-and-github-for-issues/ Enabling two way communication with WordPress and GitHub for issues].

=== Tantek ===
{{t}} has started posting issues to his own site [http://tantek.com/2018/052/b1/bridgy-github-support-images-hyperlinks 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 
*** [[article]]s 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
*** (semi-)automatically [[POSSE]]d to GitHub (depending on my Webmention sending code)

=== gRegor Morrill ===
{{gRegor}} 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 {{angelo}} 's code repository for [[indieweb.rocks]]
* https://gregorlove.com/2022/08/indieweb-rocks-issues/
* https://ragt.ag/code/indieweb.rocks

=== Add yourself! ===
{{addyourself}}

== Silo Examples ==
=== GitHub ===
[[GitHub]] allows posting of issues as part of their [[issue tracker]] feature for each repo.

== Brainstorming ==
=== 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]]:
* {{chrisaldrich}}: [https://boffosocko.com/2019/05/29/no-webmentions-to-original-urls-that-include-emojis/ bridgy: No webmentions to original URLs that include emojis]
* {{eddiehinkle}}: [https://eddiehinkle.com/2018/06/03/4/reply/ 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:
* [[#close-re-open|close]] (see below for some previous exploration of details)
* re-open
* [[#lock-unlock|lock]] (see below for some previous exploration of details)
* unlock
Only some people (the issue "creator"? the repo "owner"?) can take some/most of these actions.

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:
#. How does the GitHub API represent and support these special responses?
#. 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 <span id="close-re-open">close / re-open an issue</span> 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. [https://github.com/snarfed/bridgy/issues/827#issuecomment-392522810 Example.] The API also distinguishes [https://developer.github.com/v3/issues/events/#events-1 events] and [https://developer.github.com/v3/issues/comments/ comments], with no object for a combined-comment and-close/reopen. - {{snarfed}}
** 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. - {{t}}
* 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 [https://github.com/w3c/csswg-drafts/issues/1988#issuecomment-402620825 on GitHub]
** https://tantek.com/2020/042/t2/ and [https://github.com/privacycg/privacycg.github.io/issues/3#issuecomment-584937108 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 <span id="lock-unlock">lock / unlock an issue</span>, which blocks comments from unauthorized commenters.

How or should we model this?

Do we need to create a new type of [[response]]?

{{jacky}} 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.

== See Also ==
* [[issue tracker]]
* [[GitHub]]
* [[posts]]