issue

From IndieWeb

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


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

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:

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

Chris Aldrich

Tantek

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

gRegor Morrill

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

POSSE to Github using Bridgy:

indie site to indie site:

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:

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:

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:

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

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