GeezerVison

🐛

This article is a stub. You can help the IndieWeb wiki by expanding it with relevant information.

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:

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

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

• 2018-03-03 Chris Aldrich: Enabling two way communication with WordPress and GitHub for Issues (archived)

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)
  • 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.

IndieWeb Examples

Aaron Parecki

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

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

Tantek

Tantek Çelik 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
    • (semi-)automatically POSSEd to GitHub (depending on my Webmention sending code)

gRegor Morrill

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 Angelo Gladding 's code repository for indieweb.rocks
• https://gregorlove.com/2022/08/indieweb-rocks-issues/
• https://ragt.ag/code/indieweb.rocks

Add yourself!

Add yourself here… (see this for more details)

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:

• Chris Aldrich: bridgy: No webmentions to original URLs that include emojis
• Eddie Hinkle: 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 (see below for some previous exploration of details)
• re-open
• 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:

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

• "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?

Jacky Alciné 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

Retrieved from "https://indieweb.org/wiki/index.php?title=issue&oldid=97291"

Categories:

• PostType
• stubs