issue_comments

Table actions

2 rows where issue = 891200849 and user = 13301940 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: created_at (date), updated_at (date)

user 1

  • andersy005 · 2 ✖

issue 1

  • 0.18.1 patch release? · 2 ✖

author_association 1

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
844457262 https://github.com/pydata/xarray/issues/5298#issuecomment-844457262 https://api.github.com/repos/pydata/xarray/issues/5298 MDEyOklzc3VlQ29tbWVudDg0NDQ1NzI2Mg== andersy005 13301940 2021-05-19T20:42:25Z 2021-05-19T20:42:25Z MEMBER

Here's one example that shows github-activity in action: https://jupyterbook.org/reference/_changelog.html

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   0.18.1 patch release? 891200849
844455537 https://github.com/pydata/xarray/issues/5298#issuecomment-844455537 https://api.github.com/repos/pydata/xarray/issues/5298 MDEyOklzc3VlQ29tbWVudDg0NDQ1NTUzNw== andersy005 13301940 2021-05-19T20:39:43Z 2021-05-19T20:39:43Z MEMBER

Glad to hear that releasing is getting easier/simpler :)

There are some smaller tasks we can put into pipelines if we want to squeeze more out there (e.g. updating stable branch, adding contributor lists). The only really necessary tasks are writing the summary, organizing the whatsnew, sending out communications.

I've been thinking about this, and I'm wondering if something like this great tool: github-activity could help us (at least with updating whatsnew.rst). github-activity is able to generate the changelog from the GitHub API. This would eliminate the need for updating whatsnew.rst multiple times (once for each PR). With proper labels, github-activity is able to categorize PRs and Issues during the changelog generation. Another cool feature of github-activity is that it includes other contributions in addition to the default PR submissions: https://github-activity.readthedocs.io/en/latest/#how-does-this-tool-define-contributions-in-the-reports

There's an extreme end of "constantly release new main branches". I don't see anything functionally wrong with that, but I'm sure there are unexplored consequences, and I'm not sure our role is to forge a new path in OSS release cycles.

I'm curious.. How are these "new main branches" different from git tags from releases?

So maybe monthly is a reasonable balance?

👍🏽 for frequent/monthly release cadence 

{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   0.18.1 patch release? 891200849

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE [issue_comments] (
   [html_url] TEXT,
   [issue_url] TEXT,
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [created_at] TEXT,
   [updated_at] TEXT,
   [author_association] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [issue] INTEGER REFERENCES [issues]([id])
);
CREATE INDEX [idx_issue_comments_issue]
    ON [issue_comments] ([issue]);
CREATE INDEX [idx_issue_comments_user]
    ON [issue_comments] ([user]);