Purpose

This accompanies https://github.com/ipfs/js-ipfs/issues/4336. We don’t have everything in Github is so we can take advantage of of quicker contextual commenting and easy for seeing changes someone made. Github issues or wiki pages don’t allow for contextual highlight comments, and this deprecation involves a decent amount of messaging review.

Process for Issues

Process Steps

Owners go through each issue assigned to them per https://github.com/orgs/ipfs/projects/26/views/1. As part of this they:

  1. Triage issue and set label and messaging per Issue Closure Labels and Messaging
  2. If we haven’t closed the issue, we should set an appropriate next step.
  3. Potentially set the status to “Blocked” if needing triage or messaging help. (The status will automatically set to “Done” when the issue is closed.)

How are we capturing important metadata about issues?

There is important metadata we need to capture about each issue. This metadata is being captured in Github in the issues themselves and in the corresponding project board for the deprecation since project boards allow associating arbitrary metadata to any issues on the board.

  1. Who is doing the initial triage of the issue (@Alex Potsides, @Russell Dempsey, @Anonymous)
    1. @Russell Dempsey will modify the script in https://gist.github.com/SgtPooki/8c1d6d1e4d9ff6af87d8578f3995f970 to set the corresponding assignee.
      1. Note this is done as of May 17, 2023 12:09 PM (PDT)
  2. What category/bucket we’re putting it in (see list in Issue Closure Labels and Messaging)
  3. What is the next step?
    1. Next steps could include:
      1. Categorize - Thee issue needs to be categorized. This is the default next for anything that hasn’t been handled.
      2. Post messaging - This next step is only relevant for the case where we have categorized the issue but haven’t posted the messaging yet, likely because the messaging hasn’t been nailed down or there’s questions about how to message it.
      3. Migrate issue (presumably moving to Helia repo) - This is for issues that we want to migrate over to Helia. We
      4. None - issue has been closed or migrated - This corresponds to issues whose status is “Done”
    2. We could use github labels for this or github projects for this
      1. @Steve (biglep) setup a “Next step” field in the project board
  4. Generally last modified date, and specifically when we put the issue in the the requestor’s court.
    1. We get last modified date by default from GitHub

Our mechanism for capturing this metadata in a consolidated view is to use a Github project board for the deprecation. This is preferred over storing the metadata outside of github in a Notion database like Sync of open issues in js-ipfs or in a Google sheet so we reduce the number of tools at play.

Will we give a user time to respond before we close?