snarfed/bridgy – feature request: backfeed for status changes

snarfed/bridgy (GitHub)

bridgy – Bridgy pulls comments and likes from social networks back to your web site. You can also use it to publish your posts to those networks.

snarfed/bridgy – feature request: backfeed for status changes

I would like bridgy to backfeed status changes so that POSSE’d issues can capture the full lifecycle of an issue.

Looks like there are tons of events: https://developer.github.com/v3/issues/events/

  • vital:
    • closed
      The issue was closed by the actor. When the commit_id is present, it identifies the commit that closed the issue using “closes / fixes #NN” syntax.
    • reopened
      The issue was reopened by the actor.
    • assigned
      The issue was assigned to the actor.
    • unassigned
      The actor was unassigned from the issue.
    • renamed
      The issue title was changed.
  • important:
    • marked_as_duplicate
    • unmarked_as_duplicate
    • labeled
    • unlabeled
    • milestoned
    • demilestoned
    • locked
    • unlocked
    • review_dismissed
    • review_requested
    • review_request_removed
  • useful?:
    • referenced
    • mentioned

5 responses on “snarfed/bridgy – feature request: backfeed for status changes”

  1. I’d love this too! sadly there’s no comprehensive way to get all events on all issues that involve you. i can get a few beyond comments, best effort, but only a few, and that subset isn’t entirely predictable. background: https://brid.gy/about#GitHub+responses, https://github.com/snarfed/bridgy/issues/333#issuecomment-362101845

    i can definitely consider supporting the events that come back from the notifications API though! i worry a bit that the subset it includes will generate more confusion than it’s worth, but maybe that’s overthinking it.

  2. here’s the subset in the notifications API, ie that we can reasonably get: https://developer.github.com/v3/activity/notifications/#notification-reasons

    > assign You were assigned to the Issue.
    > author You created the thread.
    > comment You commented on the thread.
    > invitation You accepted an invitation to contribute to the repository.
    > manual You subscribed to the thread (via an Issue or Pull Request).
    > mention You were specifically @mentioned in the content.
    > state_change You changed the thread state (for example, closing an Issue or merging a Pull Request).
    > subscribed You’re watching the repository.
    > team_mention You were on a team that was mentioned.

    of those, `assign`, `mention`, and `state_change` are the meaningfully new/different events that could make sense for bridgy to support.

    next steps: figure out mf2 for those, and then see some indie example posts in the wild. feel free to help with either or both!

  4. understood! which status changes above specifically are blocking you?

    and as mentioned here and in #915, one big thing we’re waiting on here is to see example posts in the wild, with concrete mf2, for these kinds of status changes in the wild. please do take the lead and post some of those!

    (also, as usual, PRs are welcome! these should definitely be straightforward to implement in granary. i’m happy to help! https://granary.readthedocs.io/en/stable/#development is a great place to start.)

Leave a Reply