Initial governance document for the Binder project #100
Conversation
|
<3 awesome! I don't see 'suggestion' beta feature, unfortunately. Do add me as 'red'? |
|
@yuvipanda i just learned about this myself, it seems that if you press "add comment", you will have a button in the comments toolbar section to the left of to buttons like "Add bold text <ctrl+b>". Then you get a field to change that single line you have commented on prepopulated with the current lines content. The preview functionality did not work great, but after submitting the comment it shows up in green pluses and red minuses. |
Co-Authored-By: betatim <betatim@gmail.com>
If you don't see the "add suggestion" feature (Erik's description is spot on) comment here and I will add you. |
|
Thanks for the pointer, @consideRatio! I've made a suggestion, but I see @betatim has already added me :) |
|
Meta question - is it the intent for binder to separate from Jupyter and be a separate project then? I am fine with that (or not), but that intent and a transition plan should be explicit. Also, would binder join NumFOCUS? If that is not the intent, then I don't think it is clear what it means for Jupyter to have a child project with its own (and different) formal governance model. While that could be explored, it would be a separate discussion that intersects ongoing discussions about Jupyter's governance model. |
|
@ellisonbg I agree that that's an important question, but I think that should be a separate issue. AFAICT, this document is primarily about defining team responsibilities, roles and a ladder of how to transition between roles. IMO, that's separate enough from the important discussion about NumFOCUS / Jupyter that we shouldn't mix the two. I've opened #101 for that discussion. |
|
My initial thought is these two issues are not separable. However, the governance model being proposed here is quite informal and not very different from how other Jupyter subprojects (lab, hub, widgets, kernel, etc.) operate in practice. Because of that I don't think it is likely to cause any actual problems in practice, especially because there is strong overlap of the binder/jupyter teams. At least in the short term... In the medium term, the Jupyter Steering Council has been discussing refactoring the Jupyter governance model, and there is new activity/interest on that front. I have no idea what the refactored governance model of Jupyter will look like, but one of the important questions that has to be tackled is how the governance of the project as a whole interacts with the formal and informal practices of the different subprojects. The answers to that question can be informed by the binder governance case study (that will be helpful). At the same time, Jupyter's new governance model may prescribe some aspects of subproject governance. Again, I have no idea what this will look like, I just want everyone to be aware of the full context. At a minimum, I do think the intent (to remain part of Jupyter as a subproject or not) should be explicit in this document as that is not a minor detail. |
|
Thanks for your perspective, @ellisonbg.
I disagree with this, since there's nothing in this document that prevents us from making either of those choices in the future. Making this decision also requires discussion with the broader Jupyter community, and can't be done without understanding & discussion of the Jupyter governance model itself. IMO, these are orthogonal enough that we should discuss those separately. We could maybe add a line about how we will make a decision about this in the future? As an alternative, we can have an extremely timeboxed discussion about 'to remain part of Jupyter as a subproject or not' in #101 and write that into this document. My worry is that otherwise this PR will languish unmerged for months instead, as has happened in other places. |
|
The current wording we have been using to describe the relationship between Jupyter and Binder (and the various software packages involved) is the following:
It was written as a way to describe the status quo. Unless people start opposing this I think the plan is to stick with that description and state of affairs. The main benefit of it is that it describes how things have (successfully) been for the last 12-18 months. We also use it for http://mybinder.org/about I'd be OK with adding that sentence to the document.
The Jupyter gov't refactor has been going on for a few months or longer and as a semi-outsider to it I've not perceived much progress being made. Mostly I personally don't know where to go to see current proposals or timelines etc. In the meantime, the question of "binder governance" has come up a few times (from outside parties) and it always felt like we were on a back foot when it happened. My hope is that this is the first step of us being one step ahead of things next time that happens. For me it is Ok to revise how Binder sees itself and relationship to Jupyter in the future when the Jupyter-and-subprojects model becomes clearer and use these ideas from Binder as an input to making the Jupyter-and-subprojects model. |
|
One thing I forgot: one good way of attracting new contributors, maintainers, evangelizers, etc is by making a plausible story of how you can climb the ladder of recognition within the project. In particular as one of the few things we as a project can offer contributors is recognition/bragging rights. There is additional work needed to build such a contributor highway/mountain of engagement but this describes some part of it already. What to do when people at the highest level of the project can't or don't want to be there anymore is going to become a question to which we need a good-ish answer in the next few months. While this document doesn't tackle any of those questions it does document how things are right now which is hopefully a good start for when we all get hit by that bus and a new generation has to take over. |
I think that statement is clear and communicates the current state of affairs well. My confusion here probably stems from that fact that previous binder governance discussions often pivoted around the question "should binder be part of Jupyter or a separate project?" When I was no mention of that matter in the document, it felt like it was missing a point that everyone had previously agreed was important. If that is settled (even for now) then I think including that statement in the document is more than sufficient.
Sounds good, thanks for the clarification.
+1
The "going on" is probably optimistic ;-) We have talked about it on a few occasions (going back to Fall 2016). But the actual work has mostly been stalled. However, in the last month or so there has been some new action on that front. |
I am having a tough time reconciling this with the statement that @betatim posted that Binder is a member of Project Jupyter. Seems like that is a very strong indication of current intent (I do agree that it could change in the future).
If the binder team has made a decision to remain part of Jupyter for now, I don't see a need to reconsider that at this point in time. I am mostly trying to understand what decision has been made. |
|
@ellisonbg ah, I agree with @betatim :) Binder is currently a part of Project Jupyter, and that may change in the future (or not!) pending a different discussion. I mostly wanted to make sure we didn't have to wait on a long term, forever binding decision of wether it should be part of Project Jupyter or not before merging this PR. |
|
Sounds good!
…Sent from my iPhone
On Jan 4, 2019, at 2:12 PM, Yuvi Panda ***@***.***> wrote:
@ellisonbg ah, I agree with @betatim :) Binder is currently a part of Project Jupyter, and that may change in the future (or not!) pending a different discussion. I mostly wanted to make sure we didn't have to wait on a long term, forever binding decision of wether it should be part of Project Jupyter or not before merging this PR.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I added the sentence about the relationship between Jupyter and Binder. |
|
Please add me as red @betatim. Thanks. Not sure why this is an opt in for me. |
docs/governance.rst
Outdated
|
|
||
| Membership comes with `privileges`_ and `responsibilities`_. | ||
|
|
||
| Currently, the Binder Project team overlaps 100% with `the BinderHub |
There was a problem hiding this comment.
Shouldn't all members of the current BinderHub team be added to the list of names?
There was a problem hiding this comment.
I didn't copy and paste it because I hope having to add yourself means people will read and offer an opinion about the whole document. A bit like asking for $5 to sign up for a workshop to reduce no-shows.
If we get close to the deadline and are missing people we need to think up a plan to fix that.
There was a problem hiding this comment.
There is also the question of which colour people prefer that I didn't want to presume/choose for people.
There was a problem hiding this comment.
@betatim I slightly edited your top-level comment to bold the sentence where you ask people to add themselves via suggestions, I hope that's ok. I missed it too :-P
docs/governance.rst
Outdated
| * Carol Willing (red) | ||
| * Your Name (red or blue) | ||
|
|
||
| Team privileges |
There was a problem hiding this comment.
These apply to both red+blue team members unless otherwise stated, right?
There was a problem hiding this comment.
Correct. Currently we reserve the right to nominate new members to red. I'd change that and instead better define what "speak for the project" means and make that a priv for red members. For me it would be that if you want to give a talk at a conference or something it is clear who can say things that aren't otherwise written down/public. I don't know if that is a useful/desirable privilege though.
There was a problem hiding this comment.
More broadly I'm just not sure where these roles came from? I don't remember discussing this at the last meeting?
There was a problem hiding this comment.
These came from discussions in #42. There were no in person discussions.
There was a problem hiding this comment.
or put another way, we are in the middle of the discussion right now :-)
docs/governance.rst
Outdated
| comments and ideas on the GitHub issues or in the Binder gitter channel. | ||
| They should strive to make project decisions that reflect these | ||
| community opinions. | ||
|
|
There was a problem hiding this comment.
| In addition, red team members are charged with growing | |
| the Binder community and ensuring that we create an open and inclusive | |
| culture for users and future team members. |
There was a problem hiding this comment.
I didn't take over this suggestion as is. Instead I added 09325b4. What do you think of that?
|
Thanks for reading and commenting @lheagy! All your changes got implemented. |
|
|
||
| The Binder Project pursues this mission by advancing the tools | ||
| surrounding BinderHub, an open-source tool for hosting ad-hoc | ||
| environments in the cloud. The project also serves as the primary |
There was a problem hiding this comment.
is the unit the environment or the repository?
There was a problem hiding this comment.
Environment, I think. GitHub's units are repositories, we use them to build an environment people can run.
|
@Zsailer Passing along in case you are interested... |
|
Just a quick note: once this PR gets merged, I'll update the team-compass teams page to reflect red and blue teams |
Co-Authored-By: betatim <betatim@gmail.com>
|
There are two days left till we merge or close this PR. If you are unsure if you should add yourself or need help with doing so: find me on gitter or email me |
|
No objections have been registered in public or in private with me. Unless someone else is aware of privately registered objections I propose we merge this PR as a sign that it has been officially adopted. Further changes to it via the procedures laid out in the document. |
|
+1 from me - other folks should feel free to propose PRs adding their names to the teams as well. |
|
Merge then @choldgraf ? |
|
Will merge later today if there are no objections. |
To make sure we don't accidentally leave people off.
|
@yuvipanda I was thinking of adding them as "green" members, since that's explicitly for people who are still members of the project just not super active currently (and that they can explicitly make themselves red/blue members if they'd like in a subsequent PR). WDYT? |
|
@betatim @yuvipanda what about something like this: betatim#2 that PR does the following:
The teams page would now look like this:
|
|
(if you'd like, we can also merge this now and I'll open a PR for the changes above, just thought I'd propose it since it's a design-level change and not a content-level change) |
|
I like your re-org and think it is better that way. I would merge this PR first, then open a new one with your changes @choldgraf. Less confusing than a PR to the PR (I think). |
|
Wanted to make sure their names were in there, am happy for it to be however y'all wish it to be :) |
|
I also agree with @betatim - we should merge this first and do the PR afterwards. |
|
mergy merge merge! 🎉 |
|
thanks @betatim for pushing this through, and thanks to everybody else for their thoughts, comments, improvements, etc! |
|
Whoop! This has been a hard piece of work so thanks everyone for making this happen! I was a bit worried as these topics sometimes cause conflict and discussions with a harsh tone etc but we managed to avoid all that which makes me super happy. Thanks for helping make it so! |
|
Yep! I'm cool with that. I totally forgot to add myself 😅 |
This is an output from #42.
Please add yourself (via a "GitHub suggestion") to the team with either a red or blue team role.
This PR will stay open for 14 days (till 18 January 2019). After this it will be either merged (signalling acceptance) or closed (signalling rejection).
I don't think this document is perfect but it achieves an important step: it lays out in writing the process the team uses to make decisions. These decisions could be to change the document in the future. Bootstrapping is a bit awkward as we can't decide things without a decision on how to make decisions which would require us to have a system for making decisions. As such my aim is to compromise on almost everything in this document except for getting a decision making process accepted. Once we have that we can use it to change things we want to improve in this document.
It would be great if you could signal your "I agree with this" by making a comment in this PR stating that. If you disagree please also comment with a suggestion for what to change and your desired wording. If you can't agree or disagree please comment stating so and if possible what is missing to get you to a yes/no.