Give Eric Charles Commit Rights to JupyterLab

[saulshanabrook]

AFAIK we don't currently have a formalized process for giving someone commit rights to JupyterLab. I would like to move @echarles forward through that process, despite it not existing.

So this issue serves two purposes, to open a discussion about if he should be given commit rights and to propose a general framework for that process in the future.

Meta

When I got commit rights, I believe the conversation was that as long as I felt like I was committed to the project, then they it was an appropriate decision. The assumption was that people are encouraged to be humble and would likely ask for commit rights after the time in which it would be appropriate to give it to them.

If we step back and ask "What does commit rights do for you?" from a technical standpoint it lets you merge PRs and triage issues.

So if we want to make this process a bit more explicit, a criterion for being a committer is that the existing maintainers are confidence you will use that actions responsibly.

Thinking of how Python handles adding new core contributors, it seems like someone creates a post nominating someone, then the rest of the team votes. We have no defined team voting process really in JupyterLab and instead operate by consensus.

So for the process, I propose we open an issue in this repo to nominate someone to be a committer. We give some reasons why. And people comment if they have opinions. And we talk about it at our weekly meeting to come to consensus.

Unfortunately, I find it a bit weird to talk about someone in the third person publicly and put them through a public review process, as if they were a piece of code. However, the other way to do it might be to just bring it up at the weekly meeting, which I feel like has the drawback of not being as transparent. And part of the goal of this process is for others outside the process to be able to understand the process and think "If I want to contribute to core, these are the steps I need to take to get there." So I think it has some value on the encouraging-contribution front.

Eric

Eric has been participating now for a while, at least since the last JupyterLab core meeting which was last winter. He came to that meeting and worked with @Zsailer to help figure out how to get JupyterLab moved to the new Jupyter Server. He has experience working with other open source notebooks before then (I believe Zeppelin, but I could be wrong about that). He has reviewed 9 PRs, authored 14 PRs (10 merged), and participated in 15 issues .

The reason this is coming up now for me, for full disclosure, is that he has been working with me through Quansight to help a few of our clients who have JupyterLab needs. So selfishly speaking, if he is able to commit to core this means he can have more autonomy there, and I can be more freed up for other work (like the RTC grant). It has also given me a chance to work closely with him, and I am have been really impressed not only by his technical abilities but also his level head and ability to iterate through the complicated and conflicting opinions that come up when moving through a large project like this, with many stakeholders. So although it's our working relationship that spurred this proposal, I would still support his addition as a core maintainer regardless of that.

I also want to take this opportunity to thank him for his continued participation in this community ❤️

[afshin]

👍 to @echarles having commit rights.

I don't have a well thought out ideas on how a formal process should look on new committers. I can imagine wanting a less formal process because some people prefer to keep a low profile. But I can also appreciate having a well-defined and public request as well. I am curious what others think.

Thanks for your contributions, Eric. And thank you for starting this discussion, Saul.

[echarles]

Thx Saul for opening this and for the trust and empowerment you have given me so far. Although me have collaborated recently more on a business way, I would say we all shine when we have motivation to innovate in an open way.

And really impressed, Saul, with your ability to define, manage and deliver ambitious goals.

He has experience working with other open source notebooks before then (I believe Zeppelin, but I could be wrong about that).

Correct, I have contributed various fixes and enhancements for Apache Zeppelin, included the R interpreter (see also [1] back in 2002 for contribution on apache other projects, included PMC member of Apache James).

Regarding the process proposals, I think the public discussion about someone maybe a bit risky. I have no issue here about my case (if I do not get the commit right, it will not be an affair for me) and we also agreed before hand in private that you would do that, but for other case this may be an affair. I would maybe suggest to have a prior discussion in a private repo (which I think you have to pay now in GitHub). But maybe I am biased by my Apache background were a vote on the private mailing list between the committers happens before making any positive outcome public (the nominee having the opportunity to accept or refuse because with great power comes great responsibility)

[1] https://markmail.org/search/?q=eric%20charles#query:%22eric%20charles%22%20order%3Adate-forward+page:1+state:facets

[choldgraf]

Hey all - in case it is helpful, here are the team guidelines that the JupyterHub/Binder communities use for inviting and onboarding folks: https://jupyterhub-team-compass.readthedocs.io/en/latest/team/adding-members.html

[Zsailer]

:+1: for @echarles 🚀

Much of the Jupyter Server work would not have been possible without Eric's patience, persistence, and contribution. He's reliable, kind, and easy to work with. The Jupyter Community is lucky to have him—Eric's the man! 😎

[saulshanabrook]

@echarles

I think the public discussion about someone maybe a bit risky. I have no issue here about my case (if I do not get the commit right, it will not be an affair for me) and we also agreed before hand in private that you would do that, but for other case this may be an affair.

Yeah I am :+1: to this. I agree it would be best to have the initial conversation privately in the future. Thanks for offering yourself up as our public Guinea pig!

@choldgraf thanks for the link. In it, the first step is:

The champion should first discuss internally with team members to get buy- in and ensure that there’s general consensus before officially starting the process.

So what if we had a private version of the team-compass repo that was only accessible to existing contributors? On there we could open an issue to discuss whether to add someone to the core team. If the answer was yes, then we could even move the issue to the public one, pending their affirmation that they would want the role and would be OK moving the discussion publicly. Or just keep the issue private, if we think it's not appropriate to make it public.

I do think the one advantage of eventually moving some of the decision making public, if all parties are OK with it, is that it gives outsiders a way to understand the process and hopefully empowers them to see themselves in that position in the future.

[afshin]

This is a great thing to talk about today in the weekly call (at 9AM Pacific Time https://zoom.us/my/jovyan).

We also might consider whether/when to remove people from the contributors group for security and other reasons.

[choldgraf]

I'm a +1 on making these conversations public as well. I think the main reason we suggested getting private buy-in first was to avoid some of the awkwardness around talking about another person publicly that you allude to in your first post @saulshanabrook.

[jasongrout]

I'm +1 on a private conversation, and then a public introduction once someone receives commit rights, which might summarize some of the nomination discussion.

[ellisonbg]

One of the gaps we have had in the past when new contributors have come along is that we haven't done a good job in teaching them about how we build software and think about the community and our users. This has led to people being given commit rights early, and then later being surprised by the nature of the project. This situation will be helped by the work we are doing on the mission, vision and values of Jupyter, but I don't think that entirely covers it.

To help with this and bring new committer up to speed, I would love to see a mentorship program where an existing committer meets with the new one on a regular basis, helps review their PRs, etc. To help organizations mix well, I think the mentor should be from a different org than the new committer.

I would structure the mentor-mentee meetings as a weekly standup style meeting, where the agenda is to cover what the person has worked on, what they plan on working on, and what they are blocked by. In this context, this structure is mostly a mechanism to allow the important topics to bubble up.

[choldgraf]

To echo Brian's point (and to again shamelessly plug the JupyterHub team docs) it's also helpful to have something like an "onboarding check-list" that explains things like how the team operates, where the repositories are, how to get permissions for things, etc. If anybody is curious, here's the JupyterHub one: https://jupyterhub-team-compass.readthedocs.io/en/latest/team/adding-members.html#the-onboarding-checklist

OK I promise that I won't shamelessly plug again (probably)

[blink1073]

Thanks @choldgraf for sharing the knowledge!

Also, an enthusiastic 👍 to add @echarles from me.

[tgeorgeux]

I am very :+1: for @echarles being on the core team.

I think we should continue the discussion around the onboarding process.

[jasongrout]

Definitely +1 from me too to Eric getting commit rights.

Also, in the dev meeting discussion, there were many more that expressed support.

[saulshanabrook]

Cool, I think we have enough +1's to call that consensus, and no one raised objections. So I opened https://github.com/jupyterlab/jupyterlab/pull/8513 to add Eric to the core team in the README

[echarles]

Super Wonderful. Really proud to be even more part of this amazing team.

But just like a lot of non-committers, I was already feeling like being part of the JupyterLab team.

The main difference for me going forward is that I will have to review more PRs and take responsibility of merging them 👍 .