Closed betatim closed 5 years ago
I think this sounds good - I volunteer to help with this process!
I'd like to be involved as well, but feel like maybe I should give someone else a chance :-/
perhaps we can re-ping the issue in a couple of days and then go with people that have expressed interest?
I'm happy to help here if we need more people
I think y'all should get crackin :) I really like the steps that @betatim has identified in the issue.
No one has suggested an additional name or volunteered so I suggest Min, Chris and I get going with this. How does that sound?
Some thoughts on "Identify the main questions, challenges and requirements" that I need to write down somewhere while I have them in my mind.
From my POV these questions need answering:
Challenges:
Requirements:
Some examples I came across in the last few weeks while keeping an eye out for possible models:
I think that our first steps could be to hit the "low hanging fruit" for Binder, which IMO is low-$$$ donations, so we should figure out what kind of financial structure we need (or already have?) that can handle this.
I also think we could/should start thinking about grants to write about Binder to give it a bit more runway for development etc.
it the "low hanging fruit" for Binder, which IMO is low-$$$ donations
Do we need it to be donations in the sense of tax deductible donations? For example if you give money to a kickstarter campaign that is not a tax deductible donation (in general). Which makes me think any legal form will do.
My guess would be that wanting to receive grants places more restrictions on the legal entity as not all legal forms are eligible for grants from all sources of grants.
One further thing to ponder is creating several legal entities. Either because you want to be compatible with receiving income from multiple sources (create a corporation and a not-for-profit that work together) or because you want to maximise geographic coverage. Sometimes you have to be based in the US or Europe to be eligible/easy to work with.
A few comments in random order:
On Sat, Jul 28, 2018 at 11:35 PM Tim Head notifications@github.com wrote:
it the "low hanging fruit" for Binder, which IMO is low-$$$ donations
Do we need it to be donations in the sense of tax deductible donations? For example if you give money to a kickstarter campaign that is not a tax deductible donation (in general). Which makes me think any legal form will do.
My guess would be that wanting to receive grants places more restrictions on the legal entity as not all legal forms are eligible for grants from all sources of grants.
One further thing to ponder is creating several legal entities. Either because you want to be compatible with receiving income from multiple sources (create a corporation and a not-for-profit that work together) or because you want to maximise geographic coverage. Sometimes you have to be based in the US or Europe to be eligible/easy to work with.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jupyterhub/team-compass/issues/42#issuecomment-408655581, or mute the thread https://github.com/notifications/unsubscribe-auth/AABr0GghnjhujzlSTECP749i_MJ7BpnCks5uLVe9gaJpZM4UcMyd .
-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com
One big question that is unclear to me: what is the purpose of this legal entity? Hold the copyright and brands associated with Binder? Employ staff? Obtain and redistribute money? Operate the mybinder.org service to shield us from liability? Set the direction of the technical development of the project? Make us look professional and not like a bunch of people who met on the internet?
I think there are many different purposes that a legal entity related to binder could have. One design process framework we are using at Cal Poly is "Why, what, how?":
I think you are right to bring up these why questions - and exploring the should be one of the first areas of work on sustainability.
On Tue, Jul 31, 2018 at 5:55 AM Tim Head notifications@github.com wrote:
One big question that is unclear to me: what is the purpose of this legal entity? Hold the copyright and brands associated with Binder? Employ staff? Obtain and redistribute money? Operate the mybinder.org service to shield us from liability? Set the direction of the technical development of the project? Make us look professional and not like a bunch of people who met on the internet?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com
Hey all - I'm gonna take a stab at @ellisonbg 's questions because I like them, and because I think we should get the ball rolling on Binder's governance so we can make sure it survives :-)
It's kinda long, just warning you all :-) feel free to make edits/comments/etc to this directly, or to just roll your own. Also I recognize I'm kind of conflating "governance" with "org chart" with "funding". So if that's too much noise, we can cut this down.
This one I'm still not sure about, but here's my approach (it's the same one I'd consider using for Jupyter as a whole):
Convene a team with the goal of:
The team's output is a formal proposal for:
Replying to from Brian https://github.com/jupyterhub/team-compass/issues/47#issuecomment-410546426
I like Brian's idea of handling the development of BinderHub and related software in one way and operations of mybinder.org in a different. In particular we seem to have a setup for developing the software that works pretty well right now (modulo on boarding new contributors...).
Operating the mybinder.org service is quite different from building the software. For example it requires a constant stream of money to pay for hosting and people constantly ready to react to outages.
Hey all - I'd love to add another gentle ping to this one. Maybe I can do so by proposing something specific :-)
Note: this is just a proposal to try and get a conversation going, please feel free to edit, comment, criticize, etc. If people would like, I can update this section as we come up with new ideas
Moved to this HackMD: https://hackmd.io/UYG1jAM9TO-bqm9yNdXyYA
mybinder.org
team. Right now these two projects are entirely overlapping. Perhaps we adopt the same governance structure for mybinder.org, and initially have the same team, but with the idea that binderhub's team may grow w/ people who are not associated with mybinder.org?I like all of the proposal except for one thing: instead of starting with governance for BinderHub I would start with a team for operating mybinder.org or for Project Binder. I think I have a slight preference for "Project Binder". However I would not make this "Project Binder" the owner or authority over the various software projects used in operating mybinder.org or other BinderHubs. This gives it the freedom to use what ever tools are best for the job and creates a model (maybe?) for how an organisation can take part in development of each of these projects. For me this is mostly about "Project Binder" not having a special position in these projects beyond what it earns from being a large contributor.
As mission statement I'd use something like:
The mission of the Binder Project is to create, advance and promote open technology that allows people to use software without having to install anything, and to support and facilitate the growth of a diverse and international community of Binder users and developers.
For me this covers operating mybinder.org (promotion and supporting the growth of a community) and contributing to tools like BinderHub, JupyterHub, Z2JH, etc (create and advance) as well as taking leadership roles in them (facilitating community growth).
I plan to read about how the ASF works a bit more to see what we can learn. https://www.apache.org/foundation/
@nayafia recently wrote Governance without foundations, which I think raises some interesting points that can help all of us think about these problems in the context of both Binder and Jupyter (including the relation between the two).
I like the article. In particular it is a good explanation of what I was trying to say about 'Project Binder' not owning/controlling any of the software project but being one of the (main) contributors to it.
One thing I wonder after reading the article is what is the structure by which these separate entities work together on a project? Let's say there is a software called X to which both Y and Z want to contribute, what is the model by which project X decides on direction, how to resolve conflict between Y and Z, etc? I think that is a big part of this governance discussion. What legal form that takes seem less relevant (LLC, foundation, fiscally sponsored, etc) because how that entity acts will be driven by those who control it more than what legal form it has.
By saying "foundations shouldn't own a project, the project has to own itself!" do we not just relabel the problem to "how should a project own itself"?
To me it's a question of how the governance on the project works. E.g. if the project had an RFC process, the question would be "who are the deciders on whether an RFC gets merged". There could be rules about this group like "no more than X% of people representing an organization can be in this group". Obviously there are ways to hack this system, but it's one approach
Thanks for sharing that blog post Fernando. I think it does a good job of describing one aspect of Jupyter’s current governance model that I am proud of. In her language Berkeley and Cal Poly are entity0 and the governance model-at least formally-puts other partner institutions at the same level. And the way we utilize NumFOCUS is similar to that of a service provider.
I think this basic model leaves a lot of challenging questions to be worked though, but serves as a solid foundation of how multiple legal entities relate and participate in the project
Sent from my iPhone
On Nov 6, 2018, at 7:52 AM, Chris Holdgraf notifications@github.com wrote:
To me it's a question of how the governance on the project works. E.g. if the project had an RFC process, the question would be "who are the deciders on whether an RFC gets merged". There could be rules about this group like "no more than X% of people representing an organization can be in this group". Obviously there are ways to hack this system, but it's one approach
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
I've updated the proposed binder project governance to be focused on "Project Binder" as opposed to BinderHub, per @betatim's comments: https://github.com/jupyterhub/team-compass/issues/42#issuecomment-432798922
do we want to turn the top-level comment into a version of this text? Alternatively, perhaps we should workshop this in the discourse instead of here?
My impression is that there is agreement on the fundamental ideas and structures. I'd like to discuss the specific wording a bit and see where we get with some iterations. In particular I think we should define some terms (we need this for the mybinder.org about page as well). So I think we should move this to a PR via a Hackmd.
I would not do this on discourse as it will lead to more people chiming in which in this case I think wouldn't be helpful. You might end up with questions about how to join the Binder team which IMHO is a non issue until that team exists. At least it seems like it would be hard to discuss the process for joining an entity that doesn't even yet exist or know what it exactly looks like. Trying to disambiguate the various terms we have and clarifying how they relate to each other is also done best with a smaller group till they agree and then you can start using that vocabulary in a bigger group.
How do we ensure that this team changes its leadership, and particularly in more diverse and inclusive ways
Terms is one good way to accomplish this, but terms are also a poor fit when there is a relatively small number of people to rotate through.
How does the BinderHub team relate to the mybinder.org team.
We can define these as two currently-identical lists of people, so that the distinction is clear and they can start to diverge. One is the over-arching body for the project, while the other is a "team" responsible for operating the service. I'd say that operating mybinder.org should fit fully under the BinderHub project.
Where does sustainability fit in with this...currently a lot of BinderHub's development happens either because of Jupyter's grant, or because of the BinderHub grant.
It is the responsibility of the leadership to sustain the project, be it through funding or community development. I would call this one of the core responsibilities.
One thing we should make sure to resolve from the start is separating the "steering council" decision-making body from significant contributor-acknowledgment/"core team" membership, etc. This is a problem in the Jupyter structure, as we lacked any mechanism for recognizing significant contributions other than being added to the ever-growing steering council, instead of leaving the steering-council as a mostly fixed-size administrative body. The decision-resolution body should be small, and whose official involvement ought to be relatively rare, while there should be a separate category which can grow infinitely of recognized contributors, core team members on any given project, etc.
@minrk those are all great points!
for all, should we move this to a hackmd? I feel like it could be easier for folks to add their own language, edits, comments etc this way.
OK, I've removed the proposed language above and moved it into this HackMD: https://hackmd.io/UYG1jAM9TO-bqm9yNdXyYA
I'd love to see folks iterate and add their own comments, edits, etc! I like @minrk 's description of "operating mybinder.org and developing the BinderHub technology is a core duty of the Binder Project, these two are currently overlapping groups of people though they may diverge over time"
I made some edits to the Hackmd trying to incorporate the comment about SC membership and recognition.
My proposal is to have a team and that anyone can become a team member upon nomination by an existing team member. In old school software project lingo a "member" is probably a "committer" or "maintainer". There is no formal limit to the size of this group.
A new role/level of membership is that of the "senior member" (not a huge fan of the name, based on "senior XXX" as a role in a company which comes after you were a junior XXX for a while). Senior members coordinate their actions amongst each other and take on responsibilities that are more management and admin related. I would like to see a way to organise this so that being a "senior member" does not imply better/more important/smarter/etc and instead means "I'd like to focus on all the things beyond writing and reviewing code for a while now". Senior members are expected to coordinate with each other in order for the project to have a coherent message towards outsiders.
I would like to find a name for the "senior member" role that does not imply seniority (if that is possible).
The current HackMD does not make any stipulations about senior members having more/less voting rights. Together with the statement that there is no limit to the overall team size we could end up in a position where we can't make consensus decisions anymore because the group is too big. I think we should defer a decision on how to solve that problem to the day when we have this problem.
Interesting to see the proposal for scikit-learn who have successfully operated with an informal governance for 10(?) years https://github.com/scikit-learn/scikit-learn/pull/12878
For a project like Binder it seems too complex (for example requiring SLEPs). For example, most PRs for scikit-learn require two +1 before they can get merged. I like that they set time limits on decisions and using 2/3 majority for many decisions.
"successfully" ;) The time limits are a recent addition and possibly still controversial. The problem they are trying to address is that senior contributors are often busy faculty and decisions and discussions get put of indefinitely because they have no deadline.
@betatim maybe senior member is "steering committee" if the role is "beyond writing code"?
@amueller I like the way Rust handles this - for any major-ish decision, they assign a "shephard" from the community to ensure that conversation on that decision moves forward. The shephard also has authority to trigger a vote if they think conversation is getting bogged down etc.
That sounds pretty great, in particular for a larger project. Though I guess it requires the shepherd to threaten to call a vote. What I perceive as the biggest problem is people not making time for discussion (not sure the others agree). To get around that the shepherd would need to set an ultimatum for discussion, not trigger a vote. Is the shepherd usually the person making a proposal?
I do think it can makes sense to have different decision making processes and groups (who is deciding) based on the type of decision.
For the everyday technical work on GitHub issues/PR, it can probably be more informal (informal voting might still be appropriate), whereas for "bigger items" (roadmap, strategy, etc) it makes sense to have a more formal process. One of the things I have been thinking about is how to very clearly delineate when a decision falls under one of those categories/processes. For example, when is something "just an ambitious PR" and when it is "big enough that it is a roadmap question."
@ellisonbg I don't want to hijack this conversation, but I don't think such a clear delineation is possible. I also think that there needs to be a conflict resolution strategy. If you disagree on something, even if small, the informal system might fall apart.
To move us back on to the topic of this issue: We now have a proposal that hasn't received changes for 11 days and the main part of the proposal hasn't been changed since 27 November. Several weeks seems like a reasonable amount of time for people to read, reflect and comment on a short document. To me this means that there is no strong disagreement with the text.
The Binder project currently has no agreed and documented way to make a decision. This is what we should aim to fix with the first proposal of a governance model. There are many more things governance can cover but without a way of making decisions, we can't accept/reject any of them.
I would propose as a next step in bootstrapping the governance of binder to make a PR with the text in the HackMD which proposes adopting it. Leaving the PR open for at most two weeks starting from 1. Jan 2019 and then either closing it in favour of a new PR with a more acceptable proposal or merging the PR which signals it has been adopted. There will be a team meeting on the third Thursday of January at which we can announce the acceptance (if it is accepted).
I'm +1 on this, with two comments on the current language:
Happy to hash through these issues in a PR
👍 to both points. My goal for the two roles was that they were seen as equivalent in prestige but with a different focus (technical work vs evangelising/coordinating).
red/blue seemed better than junior/senior but not perfect. I think we should try and find a name that doesn't imply a ranking and instead a different focus of the two positions. This might help people move between roles instead of seeing it as a ladder that needs climbing. team/community to me suggests a ranking :-/ Another name I thought about: technical/management but also seems to imply a ranking.
I think that is a good idea. Maybe we can start with an understanding that you can explicitly signal "pause my membership" which you can resume without much process. It would give us a way to solve the IMHO biggest problem: should we wait for input from X or not?
re: 1, is one group always a subset of the other? And only one group would have commit rights, correct?
re: 2, why not have two groups: active members, inactive members, and anybody can switch between these when they like?
re 2. active and inactive as membership status sounds good to me.
on 1. the idea was that there would be two roles one that is focussed on the shorter timescale tasks (e.g. reviewing work, keeping the CI running, fixing RTD builds, coordinating releases) (blue members) and a second role (red members) for those who want to focus on longer time scale things (e.g. funding, planning, coordinating, evangelising).
I don't think there are enough people in the team that we want to/can afford making the roles exclusive. You declare your focus but continue to help out with the other area. The only ranking/exclusivity I see is that if you want to be involved in red activities you need more experience with the project (probably) and be able to commit to the project for a longer time scale (someone who occasionally stops by and helps out reviewing work is valuable, someone who isn't present a lot is not useful for coordinating the project).
I would create "mountain of engagement" that defines the route to becoming a member of the team.
I would love to do a mountain of engagement brainstorm! We started one here, but there is still much to do to refine this:
https://docs.google.com/document/d/1Ji8nwmh911rjBFQfIG7kQgx1Z13fPHyKTyrGv9U5E58/edit
You / anybody else want to spend some time improving this sheet, and then using that to help define roles?
You / anybody else want to spend some time improving this sheet, and then using that to help define roles?
Yes, in a new issue. Otherwise we won't ever get anywhere I fear :)
For sure, I don't mean here, just gauging interest
Closing this as we approved the governance set out in #100.
@choldgraf can you create a new issue for the mountain of engagement?
@betatim what do you think about doing this at the team meeting?
To get the governance of the Binder project underway how about forming a small group who are responsible for wrangling the process? Their job would be to keep us on track and moving forward, delegate tasks, do some background research, make sure the right people are involved and finally make sure we come up with a concrete plan.
A suggested mandate for the Working Group (via Brian): Design and lead a process that leads to the design and implement and legal/organizational/governance structure for Binder's code base and hosted service.
The points below are a starting point for a schedule and topics to address (again via Brian):
The point of this issue is to find out what people think of this plan, the mandate for the WG, what the WG should do and who wants to serve on the WG.
Normally we could discuss this at a team meeting but the next one isn't until the end of the month so I would suggest we try and get started on this before then. Then we could have a short report/discussion of point 1. topics in the next team meeting.