New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maintainer preferences #139

Open
jakirkham opened this Issue Mar 17, 2016 · 21 comments

Comments

Projects
None yet
@jakirkham
Copy link
Member

jakirkham commented Mar 17, 2016

EDIT: This has moved to these docs in this PR ( conda-forge/conda-forge.github.io#95 ). So I have cut it from here to avoid unnecessary duplication and to avoid this potentially becoming stale/contradictory. However, it is still important to list people's general preferences regarding what they are maintaining generally to avoid overpinging. This issues has been restructured accordingly.

@jakirkham

This comment has been minimized.

Copy link
Member

jakirkham commented Mar 17, 2016

@pelson and @ocefpaf after doing a few of these, I thought we should have some concrete guidelines to make it clear what should be done in the migration. Above I have written some of my thoughts. I am totally happy to amend based on suggestions you or others have. My hope is to reduce the workload in the transfer process in terms of review time and implementation time. Maybe adding a contributing.md to the repo would help in this effort. Any feedback anyone has would be appreciated.

@ocefpaf

This comment has been minimized.

Copy link
Member

ocefpaf commented Mar 17, 2016

Awesome stuff @jakirkham! I guess we should start writing that down in the webpage.

@pelson

This comment has been minimized.

Copy link
Member

pelson commented Mar 20, 2016

Very nicely put. I've been meaning to put together a place for these kinds of guidelines, but this issue serves us well for the time being. 👍

@jakirkham

This comment has been minimized.

Copy link
Member

jakirkham commented Mar 21, 2016

Thanks guys. Glad to know I am not totally off base.

Yeah, I can see this information being incorporated in various ways. The webpage, the wiki, a CONTRIBUTING.md document here and/or one in each feedstock, linter improvements to smoke out more mistakes via warnings or errors, etc. Welcome any feedback on these and other possible ways of incorporating this information.

@msarahan

This comment has been minimized.

Copy link
Member

msarahan commented Mar 21, 2016

I really like linters + git pre-push hooks. I think many people can't be bothered to read things, and we also shouldn't depend on linting being done on only the CI side (because that encourages the bad behavior of "I'll just push and see what the CI does").

@jakirkham

This comment has been minimized.

Copy link
Member

jakirkham commented Apr 15, 2016

This is getting add to the docs ( conda-forge/conda-forge.github.io#95 ) so that we can get it somewhere with more visibility. Suggestions, edits, tweaks, and even PRs against that PR are welcome.

@jakirkham

This comment has been minimized.

Copy link
Member

jakirkham commented May 3, 2016

Some contributors to these repos were quite prolific, but may not be as actively engaged. If they specify they only want to be contacted for certain recipes or none at all, please respect their wishes also add here what recipes (if any) they would like to be notified for. If they are no longer interested in any conda recipes, make that note here as well. Before contacting anyone please consult the list below to see if that contributor has restrictions.

@asmeurer only cares about sympy or sympy dependencies.

@dan-blanchard

This comment has been minimized.

Copy link

dan-blanchard commented May 3, 2016

I care about skll, gridmap, drmaa-python, chardet, streamparse, pystorm, IO::Storm and any dependencies they have that nothing else has.

@jakirkham

This comment has been minimized.

Copy link
Member

jakirkham commented May 3, 2016

Thanks @dan-blanchard.

@jakirkham

This comment has been minimized.

Copy link
Member

jakirkham commented May 21, 2016

As part of the transfer process, we keep track of people's recipe interests here. So, am adding this below so we can track it and hopefully avoid making more noise than strictly necessary.

Yes. In general I am fine being listed as a maintainer under any project that Kris Overholt lists me as such or for any project listed as being under the dask github organization.

-- comment by @mrocklin.

This was referenced May 21, 2016

@jakirkham jakirkham changed the title Method of transfer for conda recipes Maintainer preferences Jun 18, 2016

@jakirkham

This comment has been minimized.

Copy link
Member

jakirkham commented Jun 18, 2016

As the bulk of this content was moved in this PR ( conda-forge/conda-forge.github.io#95 ) and now lives in this doc. I have restructured the message in the comment above and the title accordingly. As we still find ourselves needing to list general maintainer preferences, I have kept this open and restructured it for that purpose alone.

I hope this change is not disruptive and would appreciate feedback and thoughts on it.

@tacaswell

This comment has been minimized.

Copy link
Contributor

tacaswell commented Jun 18, 2016

@ericdill can add me as a maintainer for anything at his discretion.

For other things, mpl + mpl deps and anything i use in my day job at bnl.

@licode

This comment has been minimized.

Copy link
Contributor

licode commented Jun 19, 2016

I am OK with being listed as a maintainer on any recipes @ericdill add to conda forge.

@sigmavirus24

This comment has been minimized.

Copy link
Contributor

sigmavirus24 commented Jun 28, 2016

If you see it on http://www.coglib.com/~icordasc/projects.html you can add me to it.

@jakirkham

This comment has been minimized.

Copy link
Member

jakirkham commented Jun 28, 2016

How do you feel about legacy packages (e.g. pep8 or pep257), @sigmavirus24? Mainly we keep these around for packages that have not updated to the new name.

@ericdill

This comment has been minimized.

Copy link
Member

ericdill commented Jul 16, 2016

@wyseguy7 can add me as a maintainer for any packages at his discretion

@agoodm

This comment has been minimized.

Copy link
Member

agoodm commented Sep 18, 2016

@jarifibrahim can add me as a maintainer for any packages at his discretion

@mariusvniekerk

This comment has been minimized.

Copy link
Contributor

mariusvniekerk commented Sep 25, 2016

@ericdill can add me as a maintainer for any package at his discretion.

@parente

This comment has been minimized.

Copy link
Contributor

parente commented Mar 2, 2017

@ericdill can add me as maintainer to packages at his discretion. Anyone from the jupyter team can add me as maintainer of jupyter packages at their discretion.

@CJ-Wright

This comment has been minimized.

Copy link
Contributor

CJ-Wright commented Jul 6, 2017

@ericdill can add me as a maintainer for any packages at his discretion.

@cshaley

This comment has been minimized.

Copy link
Contributor

cshaley commented Oct 6, 2017

@sannykr can add me as a maintainer to packages at his discretion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment