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 <n...@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 > <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 > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion