[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 <tra...@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@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
