[Numpy-discussion] composition of the steering council (was Re: Governance model request)
Sebastian Berg
sebastian at sipsolutions.net
Sat Sep 26 16:03:49 EDT 2015
On Fr, 2015-09-25 at 14:15 +0000, Thomas Caswell wrote:
> 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 you are probably right, we probably do not need to document how
exactly people were picked to be in the seed. At least unless the final
list creates a headache for someone in the community, in which case a
formal definition may be easier for consensus.
Maybe I can say that if we agree to the current proposal, and you,
Travis, say that you plan to be more directly active/visible than the
last few years, then I am happy if you are in the seed.
Plus, I do have a feeling that this might come more easy now if we do
plan more regular meetings and maybe discussions on some larger issues.
However, I still do have a bit of a bad taste about doing an exception
for you to stay should you not find the time.
This is just because I like the current rules and do not like exceptions
much.
As I said, I will not get in the way of any consensus saying otherwise
though and I am sure there are many ways to change the current draft
that even I will like ;)!
- Sebastian
>
> 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
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150926/079bab37/attachment.sig>
More information about the NumPy-Discussion
mailing list