[Numpy-discussion] composition of the steering council (was Re: Governance model request)

Fri Sep 25 10:15:25 EDT 2015

To respond to the devils advocate:

 Creating this organizational framework is a one time boot-strapping
event.  You could use wording like "The initial council will include those
who have made significant contributions to numpy in the past and want to be
on it" or "The initial council will be constructed by invitation by
Nathaniel and Chuck".  More objective criteria should be used going
forward, but in terms of getting things spun up quickly doing things by
fiat is probably ok.  I am not even sure that the method by which the
initial group is formed needs to go into the governing document.

I think this addresses most of the concerns, IBM is happy (enough) because
this was done as part of a one-time boot strapping operation of standing
the rules up and there are no explicit names in the governing documents.
It also acknowledges that there is a discontinuity/singularity in the
governance of the project which means you get to do singular thing :).

Tom

On Fri, Sep 25, 2015 at 8:40 AM Nathaniel Smith <njs at pobox.com> wrote:

> [Travis: sorry for writing all this referring to you in third person
> -- I guess it might feel a bit awkward to read! You're certainly part
> of the intended audience, but then it felt even more awkward trying to
> write in second person... this is clearly a bug in English.]
>
> Hi all,
>
> On Wed, Sep 23, 2015 at 2:21 PM, Travis Oliphant <travis at continuum.io>
> wrote:
> > As the original author of NumPy, I would like to be on the seed council
> as
> > long as it is larger than 7 people.    That is my proposal.    I don't
> need
> > to be a permanent member, but I do believe I have enough history that I
> can
> > understand issues even if I haven't been working on code directly.
> >
> > I think I do bring history and information that provides all of the
> history
> > that could be helpful on occasion.     In addition, if a matter is
> important
> > enough to even be brought to the attention of this council, I would like
> to
> > be involved in the discussion about it.
>
> Regarding the question of Travis being on the council:
>
> My overall feeling on this pretty neutral: I think it won't make much
> of a difference to NumPy really either way, because the important
> thing will be Travis's insights, available time to contribute, etc.,
> and these will (I assume) be pretty much the same regardless of
> whether he's on the council or not. (Any matter so intractable that it
> actually needs the council's emergency powers will presumably be
> heralded by an epic multi-month message thread of doom, plus Travis
> has plenty of friends on the council who know where to find him when
> historical insight is needed, so I'm not worried about anyone missing
> out on a chance to be involved.) I'm sure we can make it work either
> way.
>
> But, I want to play devil's advocate for a bit, because there are some
> connected issues that IMHO we should at least think through if we're
> going to do this, and I think the easiest way to do that is to try and
> articulate the case against. So, here's the case against Travis being
> on the steering council immediately + an alternative option for
> comparison:
>
> ----- begin devil's advocate -----
>
> First, just as a procedural matter, it seems clear that putting Travis
> on the council now will require changing the document in ways that
> violate Sebastian/Chris's concept of a "no names" rule -- at least in
> spirit if not in letter. The problem isn't just the initial council
> seeding; it's that Travis formally stepped down from the project more
> than 2.5 years ago, was mostly inactive for some time before that, and
> IIRC has been almost completely unheard-from between then and a few
> weeks ago. (Of course please correct me if I'm forgetting something,
> and obviously I'm talking with respect to numpy only -- clearly Travis
> has been doing tons of great things, but while numpy certainly
> benefits from e.g. the existence of NumFOCUS, creating NumFOCUS
> doesn't really feel like what we mean by "project activity" :-).)
>
> This means that as currently written, it's pretty unambiguous: he
> doesn't qualify to be added by the normal nomination process (requires
> "sustained" activity over the last year), and if he were added anyway
> (e.g. as part of the seed council) then according to the rules he
> would then be immediately removed for inactivity (requires being
> active within the last 1 year, or else within the 2 years plus
> affirmation that they planned to "return to active participation soon"
> -- this post hoc analysis requires a bit of squinting to apply at all,
> but it's pretty hard to reconcile with >2 years inactivity + his
> "moving on from numpy to blaze" post). To avoid referencing him by
> name we could add some text about "founding developers" or something
> as a fig leaf, but judging from Robert's last email it sounds like
> Travis is the only person in question, so this really would just be a
> fig leaf.
>
> Of course we have the option of modifying the rules to make this work
> -- I'm not really sure how to do this, but it's our text and I'm sure
> we can make it do whatever we want somehow. But any kinds of special
> case modifications for a single person create two problems:
>
> 1) Given that whether or not Travis is listed on the steering council
> probably won't affect the project much or at all, it could easily
> appear to an outside observer that the purpose of these rules changes
> was not to benefit NumPy, but only to benefit Travis's ego. Not that
> there's anything wrong with massaging Travis's ego :-). BUT, it sends
> a clear message (whether we mean it that way or not): that we think
> being on the steering council should affect one's ego. And there *is*
> something very wrong with this *message*.
>
> It's crucial that serving on the steering council be understood to be
> a job, not a privilege -- sort of like being release manager. It's an
> important and valued job, we're glad people volunteer, but it's an
> absolutely fundamental rule that council members do *not* get any
> special treatment outside of specific limited circumstances. If being
> on the steering council becomes a trophy or judgement of worth, and
> being left off it becomes an insult that implies someone's
> contributions are less worthy, then we are starting down the slippery
> slope that Matthew worries about, where there's an unspoken class
> distinction between the "important contributors" and "everyone else".
> This exact problem has destroyed the community in many F/OSS projects
> (see: BSDs, XFree86, lots of modern corporate-controlled projects).
>
> Emotions get high in these discussions, but it's important to remember
> that at the end of the day all this "steering council" stuff is just
> some bureaucracy we need to get organized so that we can get back to
> the real work that matters -- no-one's worth is up for debate, and the
> steering council is just one part of the whole project. And not even
> the most important part.
>
> 2) If we change the rules in one case, then it's hard to prove to
> outside observers that the rules really are the rules and are really
> applied equally to everyone. Brian Granger was telling us at SciPy how
> this has been a major challenge for Jupyter/IPython when working with
> large companies -- they really want to have confidence in the
> governance structure before they get involved. We don't want to end up
> in a conversation like:
>
> <IBM> We'd like to contribute, but first we'd like some evidence that
> you're really a robust independent project and not subject to
> corporate capture.
> <NumPy> Well, here's our governance document, it clearly lays out the
> rules for contributions, and in particular how corporate contributions
> get no special privileges...
> <IBM> Sure, that's what it says, but the first time a well-connected
> CEO who employs the leaders of substantial portions of the numerical
> ecosystem asked, you changed the rules to give him special privileges.
> <NumPy> Well, yes, but that was an extremely special case that had
> nothing to do with the corporate stuff you just said -- it was because
> Travis is just that awesome.
> <IBM> Well, we are a faceless corporate monolith and have no idea who
> this Travis guy is, but okay, fine, he's just that awesome. Is anyone
> else that awesome? Where's the line -- what other special cases are
> there that are special enough to break the rules? The next time one
> comes up, will you follow the rules that you wrote down or do
> something else?
> <NumPy> ...we're not sure?
>
> ...that would kind of suck.
>
> So those are two problems that would apply for any special cases added
> to the rules, regardless of who particularly they were for.
>
> There's also the further concern that the steering council's main job
> is to "provide useful guidance, both technical and in terms of project
> direction, to potentially less experienced contributors" and
> "facilitate the ordinary community-based decision making procedure",
> and in Travis's case in particular, it's sort of unclear whether he's
> the best person for these jobs right now. Between his limited time
> (e.g. "I don't have time myself to engage in the community process"
> [1]) and the way the project has changed since he was actively
> involved, interactions in recent years have tended to be a bit awkward
> -- not because of any wrong-doing on anyone's part, but just because
> we're generally out-of-sync, resulting in e.g. self-merged pull
> requests [2][3] [glad to hear you don't do this anymore though!], or
> struggles to contribute to discussions based on limited context [4],
> or emails [5][6] that scare Chris Barker [7]. And usually with these
> kinds of discussions (e.g. for commit rights) you get enthusiastic
> unanimity, so Sebastian's unusually frank concerns give me serious
> pause [8]. Everyone else on the proposed steering council list
> certainly doesn't agree about everything, but we do all have ongoing
> relationships from interacting on the tracker and mailing list, making
> day-to-day decisions, and it's not clear to me that Travis even
> wants/is able to participate at that level currently.
>
> So what's the alternative option? I'd suggest: Keep the Jupyer/IPython
> rules for council member eligibility, and add Travis in a year when he
> becomes eligible by those rules. (Assuming he remains active and
> interested -- personally in his position I'd be tempted to just stick
> with the much cushier "Founder / Leader Emeritus" job -- all the
> respect, none of the day-to-day hassle ;-).) In the mean time we still
> get his insight and other contributions, and it provides a clear
> period for him ease into how we do things these days, which addresses
> Chuck and Sebastian's concerns.
>
> And, more importantly, it takes advantage of a unique opportunity: it
> takes the above negatives and turns them into positives. If later on
> someone feels slighted at not being on the steering council, we can
> say "look, even *Travis* isn't (wasn't) on the steering council --
> you've misunderstood what this means", or if IBM comes calling we can
> say:
>
> <NumPy> Look, if we were going to break the rules for anyone, we would
> have broken them for Travis. But he followed the same process as
> everyone else. That's how we do things around here.
>
> I've had several long conversations with Travis recently, and one
> thing that's been very clear is that he still sees NumPy as being his
> baby and he's hungry to find ways to help it -- but maybe struggling
> to work out how to do that most effectively. It's a thing about babies
> -- eventually they grow up, become rebellious teenagers, and then --
> if you did a good job parenting, and are very lucky -- they move out,
> have their own lives, and maybe call occasionally to ask for advice
> and money ;-). I'm not a parent, but I have been a child, and I
> understand this is often a challenging transition...
>
> In the case of NumPy, I think the last few years have shown that the
> project can more-or-less grow and succeed even without Travis -- but
> pulling a George Washington
>
> http://deadpresidents.tumblr.com/post/24687113413/did-washington-stepping-down-after-2-terms-impact
> like this would make a contribution to NumPy's long-term stability in
> a way that only Travis can do.
>
> ----- end devil's advocate -----
>
> Again, I want to emphasize that while I've tried to make as strong a
> case as I can above, my actual belief right now is that NumPy will be
> just fine either way -- especially if we can think of ways to address
> and minimize the two specific problems described above. But at the
> very least I wanted to make sure they were on the table as concerns.
>
> -n
>
> [1]
> https://mail.scipy.org/pipermail/numpy-discussion/2015-September/073564.html
> [2] https://github.com/numpy/numpy/pull/2940
> [3] https://github.com/numpy/numpy/pull/2772
> [4] https://github.com/numpy/numpy/issues/5844#issuecomment-141723799
> [5]
> https://mail.scipy.org/pipermail/numpy-discussion/2015-September/073562.html
> [6]
> https://mail.python.org/pipermail/python-dev/2015-September/141609.html
> [7]
> https://mail.scipy.org/pipermail/numpy-discussion/2015-September/073582.html
> [8]
> https://mail.scipy.org/pipermail/numpy-discussion/2015-September/073748.html
>
> --
> Nathaniel J. Smith -- http://vorpus.org
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150925/55f3425c/attachment.html>