From IndieWeb
(Redirected from ๐Ÿ›)
Jump to: navigation, search

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.


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


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


Post an issue mostly like an article, with an in-reply-to to the Issues page of the repo you are posting an issue to. See below examples for details

How to with WordPress


How to with Known

See and use:


You can POSSE issue posts to the issues collections of their respective projects.

POSSE to GitHub

You can POSSE to GitHub:

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

Chris Aldrich


Tantek ร‡elik has started posting issues to his own site since 2018-02-21

Silo Examples


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:

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

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



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

See Also