html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/1850#issuecomment-483370027,https://api.github.com/repos/pydata/xarray/issues/1850,483370027,MDEyOklzc3VlQ29tbWVudDQ4MzM3MDAyNw==,1386642,2019-04-15T18:41:22Z,2019-04-15T18:41:22Z,CONTRIBUTOR,"To be clear, I think there is some optimal middle ground between the ""mega xarray-contrib"" package and the current situation. I think the ""micro-package"" approach works when the collection of micro-packages is being maintained by an active/permanent entity (e.g. Ryan research group). On the other hand, postdocs and grad students are very likely to leave the field entirely within a few years, at which point they will probably stop maintaining their ""micro-packages"".","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,290593053
https://github.com/pydata/xarray/issues/1850#issuecomment-483342686,https://api.github.com/repos/pydata/xarray/issues/1850,483342686,MDEyOklzc3VlQ29tbWVudDQ4MzM0MjY4Ng==,1386642,2019-04-15T17:22:37Z,2019-04-15T17:22:37Z,CONTRIBUTOR,"I'd also like to thank @teoliphant for weighing in!
Bearing in mind the history of scipy, I agree that the xarray community doesn't need 100% centralization, but there should be some conglomeration. IMO, the current situation of ""one graduate student/postdoc per package"" is not sustainable.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,290593053
https://github.com/pydata/xarray/issues/1850#issuecomment-480063323,https://api.github.com/repos/pydata/xarray/issues/1850,480063323,MDEyOklzc3VlQ29tbWVudDQ4MDA2MzMyMw==,1386642,2019-04-04T21:04:37Z,2019-04-04T21:04:37Z,CONTRIBUTOR,"Thanks @rabernat that awesome list looks pretty awesome.
However, I would still advocate for a more centralized approach to this problem. For instance, the [NCL](https://www.ncl.ucar.edu/Document/Functions/Contributed/contrib.shtml) has a huge library of contributed functions which they distribute along with the code. By now, I am sure that xarray users have basically reimplemented equivalents to all of these functions, but without a centralized home it is still too difficult to find or contribute new codes.
For instance, I have a useful wrapper to `scipy.ndimage` that I use all the time, but it seems overkill to release/support a whole package for this one module. I would be much more likely to contribute a PR to a community run repository. I am also much more likely to use such a repo.
I would be more than willing to volunteer for such an effort, but I think it needs to involve multiple people. Various individuals have tried to make such repos on their own, but none seem to have reached critical mass. For example,
https://github.com/crusaderky/xarray_extras
https://github.com/fujiisoup/xr-scipy
I think there should be multiple maintainers, so that if one person drops out, there still appears to be activity on the repo.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,290593053
https://github.com/pydata/xarray/issues/1850#issuecomment-368201527,https://api.github.com/repos/pydata/xarray/issues/1850,368201527,MDEyOklzc3VlQ29tbWVudDM2ODIwMTUyNw==,1386642,2018-02-24T05:23:04Z,2018-02-24T05:23:04Z,CONTRIBUTOR,"@maxim-lian There is a very short list of such packages hidden in the [xarray documention](http://xarray.pydata.org/en/stable/internals.html?highlight=xgcm#extending-xarray).
In general, there are a ton of these `awesome-...` repos floating around the internet which just list the useful/related tools/libraries which are related to `...` . For example, there are repos out there like [awesome-python](https://github.com/vinta/awesome-python) and [awesome-bash](awesome-bash). Maybe someone could start an `awesome-xarray` package.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,290593053
https://github.com/pydata/xarray/issues/1850#issuecomment-359963097,https://api.github.com/repos/pydata/xarray/issues/1850,359963097,MDEyOklzc3VlQ29tbWVudDM1OTk2MzA5Nw==,1386642,2018-01-23T23:09:21Z,2018-01-23T23:09:21Z,CONTRIBUTOR,"I agree that the separate repository model is probably best. However, should it be in just one repository or in many?
Using many repos would solve the domain-specific dependency problem, but the sklearn-contrib packages are not that discoverable IMO. I found two of them via google on separate occasions before realizing that they were part of the same github organization.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,290593053
https://github.com/pydata/xarray/issues/1850#issuecomment-359570153,https://api.github.com/repos/pydata/xarray/issues/1850,359570153,MDEyOklzc3VlQ29tbWVudDM1OTU3MDE1Mw==,1386642,2018-01-22T21:25:53Z,2018-01-22T21:26:31Z,CONTRIBUTOR,"Thanks for starting this issue @shoyer. One thing I would be interested to know is how sklearn and tensorflow balance code-quality and API consistency with low barrier to entry. For instance, most of the sklearn contrib packages provide classes which inherit from sklearn's `Transformer`, `BaseEstimator`, or `Regressor` classes, which ensures that all the contrib packages share a common interface.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,290593053