SciPy governance model
Hi all, Starting with the summary of my email of earlier today: I'd like to push on with agreeing on a governance model and document. We had some discussions and a hangout on that last year [1]. In the hangout we decided to give people some time to read up on provided info on how this worked in other projects, the Karl Fogel book, etc. I was supposed to organize a follow-up, but failed to do so until now. I will send a separate email about this shortly. We're now at a point where most other major projects in the scientific Python ecosystem have a formal governance model. Many are modeled after the Jupyter one [2], which defines a BDFL, a steering council and contributors, and a voting system to make decisions (simplified, there's much more - the whole document is worth reading). NumPy chose another model, with a steering council and consensus-based decision making [3].
From the outside, the Jupyter model seems to be working for them. The NumPy model hasn't been exercised too much yet, but should work well too. There are variations on those two models in use as well (like the Jupyter model minus the BDFL).
An email discussion on this topic without a concrete proposal or summary document is likely to go on for a long time and may not converge easily. A video conference is also tricky, with dates/timezones and discussion often going off on tangents. So I have the following proposal: - We start by drafting an extended summary of the various models and getting a sense of which model the core team prefers. - We then work out that model, and bring it back to this list for discussion/finetuning/acceptance. - "We" here is the group of people who indicate, on this list or to me off-list, that they want to participate by the end of this week. Thoughts? Volunteers? Ralf [1] https://mail.scipy.org/pipermail/scipy-dev/2015-April/020636.html [2] Jupyter governance doc: https://github.com/jupyter/governance [3] NumPy governance doc: http://docs.scipy.org/doc/numpy-dev/dev/governance/index.html [4] Producing Open Source software (Karl Fogel): http://producingoss.com/
Hi, On Sun, Sep 4, 2016 at 1:07 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
Hi all,
Starting with the summary of my email of earlier today: I'd like to push on with agreeing on a governance model and document. We had some discussions and a hangout on that last year [1]. In the hangout we decided to give people some time to read up on provided info on how this worked in other projects, the Karl Fogel book, etc. I was supposed to organize a follow-up, but failed to do so until now. I will send a separate email about this shortly.
We're now at a point where most other major projects in the scientific Python ecosystem have a formal governance model. Many are modeled after the Jupyter one [2], which defines a BDFL, a steering council and contributors, and a voting system to make decisions (simplified, there's much more - the whole document is worth reading). NumPy chose another model, with a steering council and consensus-based decision making [3]. From the outside, the Jupyter model seems to be working for them. The NumPy model hasn't been exercised too much yet, but should work well too. There are variations on those two models in use as well (like the Jupyter model minus the BDFL).
An email discussion on this topic without a concrete proposal or summary document is likely to go on for a long time and may not converge easily. A video conference is also tricky, with dates/timezones and discussion often going off on tangents. So I have the following proposal:
- We start by drafting an extended summary of the various models and getting a sense of which model the core team prefers. - We then work out that model, and bring it back to this list for discussion/finetuning/acceptance. - "We" here is the group of people who indicate, on this list or to me off-list, that they want to participate by the end of this week.
I'm happy to help. I have some time this coming week. I know that Stefan vdW is thinking hard about these issues at the moment for scikit-image, so we may be able to collaborate with scikit-image on some of these discussions. The Jupyter (BDFL) model got picked up by at Pandas [1], and MPL [2]. The numpy model is designed for the situation where was not an obvious candidate to be project leader. So, I strongly suspect that our choice of model will come down to whether we can agree on a project leader, or agree on a way to chose one. The obvious candidates would I guess be in this list: git shortlog -ns --since "5 years ago" | head -5 1789 Pauli Virtanen 1528 Ralf Gommers 770 Evgeni Burovski 604 Alex Griffing 402 Warren Weckesser I have the impression that you (Ralf) and Pauli have also been the most active in reviewing and merging pull requests over that time. Can I humbly suggest that you 5 discuss amongst yourselves who among you would like to be project leader? If there's only one of you who wants to do that job, then the decision process about governance is much easier. If there are several of you who want to do the job, it's still easier, because we can just work out a voting process to select you. I think we should consider the numpy governance model, only if there are none of you who want to be leader. Thanks for bringing up the discussion, Matthew [1] https://github.com/pydata/pandas-governance [2] https://github.com/matplotlib/governance/pull/1
So, I strongly suspect that our choice of model will come down to whether we can agree on a project leader, or agree on a way to chose one. The obvious candidates would I guess be in this list:
git shortlog -ns --since "5 years ago" | head -5
1789 Pauli Virtanen 1528 Ralf Gommers 770 Evgeni Burovski 604 Alex Griffing 402 Warren Weckesser
I have the impression that you (Ralf) and Pauli have also been the most active in reviewing and merging pull requests over that time.
As far as I'm concerned, I always considered these two individuals as project leads.
I think we should consider the numpy governance model, only if there are none of you who want to be leader.
Agreed --- it's better to have at each point in time a person with deciding vote or veto. Or two persons. And for a really low-probability case where they two cannot agree, they together designate a third one. (Not sure we need to worry about that possibility though.) If we want to be fancy and can't find a better alternative, we can consider a EU presidency model where the deciding vote position is rotating among the dev team on a time basis.
On Mon, Sep 5, 2016, at 12:42, Evgeni Burovski wrote:
If we want to be fancy and can't find a better alternative, we can consider a EU presidency model where the deciding vote position is rotating among the dev team on a time basis.
As Matthew mentioned, I am indeed very interested in this conversation, since we're also investigating potential governance models for scikit-image. My feeling is that having a clear leader in place is important, so I'm also leaning away from the numpy model towards one where responsibilities are more explicitly assigned. Exactly how to best make that assignment is still unclear to me. Stéfan
My feeling is that having a clear leader in place is important, so I'm also leaning away from the numpy model towards one where responsibilities are more explicitly assigned. Exactly how to best make that assignment is still unclear to me.
+1 for BD(FL) / leader-style from me, too. I like Matthew's suggestion of the top 5 active folks discuss to see which of them are actually interested in taking on that role. Eric
On Wed, Sep 7, 2016 at 1:37 AM, Eric Larson <larson.eric.d@gmail.com> wrote:
My feeling is that having a clear leader in place is important, so I'm
also leaning away from the numpy model towards one where responsibilities are more explicitly assigned. Exactly how to best make that assignment is still unclear to me.
+1 for BD(FL) / leader-style from me, too. I like Matthew's suggestion of the top 5 active folks discuss to see which of them are actually interested in taking on that role.
Thanks for the feedback everyone. Looks like everyone likes this suggestion so far, so we'll give that a try. And Matthew, thanks for the offer to help with drafting some docs. I'll contact you off-list about that. Cheers, Ralf
On Sat, Sep 10, 2016 at 10:25 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Wed, Sep 7, 2016 at 1:37 AM, Eric Larson <larson.eric.d@gmail.com> wrote:
My feeling is that having a clear leader in place is important, so I'm
also leaning away from the numpy model towards one where responsibilities are more explicitly assigned. Exactly how to best make that assignment is still unclear to me.
+1 for BD(FL) / leader-style from me, too. I like Matthew's suggestion of the top 5 active folks discuss to see which of them are actually interested in taking on that role.
Thanks for the feedback everyone. Looks like everyone likes this suggestion so far, so we'll give that a try.
Hi all, I'm happy to report that we've worked this out. Pauli was our preferred candidate, and he has agreed to take up the role of BDFL! Cheers, Ralf
And Matthew, thanks for the offer to help with drafting some docs. I'll contact you off-list about that.
Cheers, Ralf
Hi, On Tue, Sep 13, 2016 at 2:03 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sat, Sep 10, 2016 at 10:25 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Wed, Sep 7, 2016 at 1:37 AM, Eric Larson <larson.eric.d@gmail.com> wrote:
My feeling is that having a clear leader in place is important, so I'm also leaning away from the numpy model towards one where responsibilities are more explicitly assigned. Exactly how to best make that assignment is still unclear to me.
+1 for BD(FL) / leader-style from me, too. I like Matthew's suggestion of the top 5 active folks discuss to see which of them are actually interested in taking on that role.
Thanks for the feedback everyone. Looks like everyone likes this suggestion so far, so we'll give that a try.
Hi all, I'm happy to report that we've worked this out. Pauli was our preferred candidate, and he has agreed to take up the role of BDFL!
Great job - thanks very much for working that out. I'm going to take this opportunity to express my gratitude and admiration for the patient, committed and high-quality work you guys have been doing over a long period, on all fronts. We owe you a great debt. Cheers, Matthew
On Tue 13 Sep, 09:50, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi all, I'm happy to report that we've worked this out. Pauli was our preferred candidate, and he has agreed to take up the role of BDFL!
Great job - thanks very much for working that out.
I'm going to take this opportunity to express my gratitude and admiration for the patient, committed and high-quality work you guys have been doing over a long period, on all fronts. We owe you a great debt.
Well said Matthew. Thanks a lot to all of you from me too and special thanks to Pauli! -- Tiziano
On Tue, Sep 13, 2016 at 9:03 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sat, Sep 10, 2016 at 10:25 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Wed, Sep 7, 2016 at 1:37 AM, Eric Larson <larson.eric.d@gmail.com> wrote:
My feeling is that having a clear leader in place is important, so I'm
also leaning away from the numpy model towards one where responsibilities are more explicitly assigned. Exactly how to best make that assignment is still unclear to me.
+1 for BD(FL) / leader-style from me, too. I like Matthew's suggestion of the top 5 active folks discuss to see which of them are actually interested in taking on that role.
Thanks for the feedback everyone. Looks like everyone likes this suggestion so far, so we'll give that a try.
Hi all, I'm happy to report that we've worked this out. Pauli was our preferred candidate, and he has agreed to take up the role of BDFL!
Hi all, it has taken a while longer than I had planned, but here is a PR with the draft governance doc: https://github.com/scipy/scipy/pull/6953. Review and feedback very welcome. If there's something really major about the structure of it, this list is probably a better place to discuss then on the PR. Cheers, Ralf
Hi, On Wed, Jan 11, 2017 at 1:13 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Tue, Sep 13, 2016 at 9:03 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sat, Sep 10, 2016 at 10:25 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Wed, Sep 7, 2016 at 1:37 AM, Eric Larson <larson.eric.d@gmail.com> wrote:
My feeling is that having a clear leader in place is important, so I'm also leaning away from the numpy model towards one where responsibilities are more explicitly assigned. Exactly how to best make that assignment is still unclear to me.
+1 for BD(FL) / leader-style from me, too. I like Matthew's suggestion of the top 5 active folks discuss to see which of them are actually interested in taking on that role.
Thanks for the feedback everyone. Looks like everyone likes this suggestion so far, so we'll give that a try.
Hi all, I'm happy to report that we've worked this out. Pauli was our preferred candidate, and he has agreed to take up the role of BDFL!
Hi all, it has taken a while longer than I had planned, but here is a PR with the draft governance doc: https://github.com/scipy/scipy/pull/6953.
Review and feedback very welcome. If there's something really major about the structure of it, this list is probably a better place to discuss then on the PR.
The main question I'd like to raise, is whether we really want a BDFL, as opposed to an elected projected leader. I think a BDFL makes sense where there's one person who started the project, wrote most of the code (at least at some point in the project's history), has been in charge since the beginning, and is still very active. I think that does correspond to the situation for Linus / Linux; Guido / Python; and Fernando / IPython. I don't think we have anyone matching that description in Scipy. On the other hand, I do think it's important to have a project leader, with final authority on the direction of the project, and who takes responsibility for the health of the project. So, I propose, rather than have a BDFL, we have a system for choosing a leader, say every 4 years, where we may or may not have limits on the number of consecutive terms. We can use that 4 year cycle to make sure we're reconsidering the direction of the project regularly, and thinking about where we could improve, and where we might be messing up. It provides a natural way to give people a rest from the job, if they want one. If one leader steps back, and sees another leader doing something better than they did, they can learn from that when they next have a leadership term. Of course that requires some formalization, but I think it's a considerably better system than the BDFL, for our case. Cheers, Matthew
On Fri, Jan 13, 2017 at 8:22 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Wed, Jan 11, 2017 at 1:13 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Tue, Sep 13, 2016 at 9:03 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sat, Sep 10, 2016 at 10:25 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Wed, Sep 7, 2016 at 1:37 AM, Eric Larson <larson.eric.d@gmail.com> wrote:
My feeling is that having a clear leader in place is important, so I'm also leaning away from the numpy model towards one where responsibilities are more explicitly assigned. Exactly how to best make that assignment is still unclear to me.
+1 for BD(FL) / leader-style from me, too. I like Matthew's suggestion of the top 5 active folks discuss to see which of them are actually interested in taking on that role.
Thanks for the feedback everyone. Looks like everyone likes this suggestion so far, so we'll give that a try.
Hi all, I'm happy to report that we've worked this out. Pauli was our preferred candidate, and he has agreed to take up the role of BDFL!
<snip>
The main question I'd like to raise, is whether we really want a BDFL, as opposed to an elected projected leader.
I think a BDFL makes sense where there's one person who started the project, wrote most of the code (at least at some point in the project's history), has been in charge since the beginning, and is still very active. I think that does correspond to the situation for Linus / Linux; Guido / Python; and Fernando / IPython. I don't think we have anyone matching that description in Scipy.
On the other hand, I do think it's important to have a project leader, with final authority on the direction of the project, and who takes responsibility for the health of the project.
So, I propose, rather than have a BDFL, we have a system for choosing a leader,
Which is exactly how it worked this time --- using the system of your suggestion, https://mail.scipy.org/pipermail/scipy-dev/2016-September/021476.html
say every 4 years, where we may or may not have limits on the number of consecutive terms.
While I agree that this model is better in the vast majority of situations, it feels to be a bit of over-engineering for scipy.
We can use that 4 year cycle to make sure we're reconsidering the direction of the project regularly, and thinking about where we could improve, and where we might be messing up. It provides a natural way to give people a rest from the job, if they want one. If one leader steps back, and sees another leader doing something better than they did, they can learn from that when they next have a leadership term.
I agree it's worth it to periodically sit down and think about the direction of the project. I'm not sure though there is benefit in tying this up to a machinery of fixed-time leadership terms, holding formal elections and so on.
Of course that requires some formalization, but I think it's a considerably better system than the BDFL, for our case.
It seems to me that the effort needed to formalize it is not worth the benefit, specifically in our case. My 2 cents, Evgeni
Hi, On Fri, Jan 13, 2017 at 3:24 PM, Evgeni Burovski <evgeny.burovskiy@gmail.com> wrote:
On Fri, Jan 13, 2017 at 8:22 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Wed, Jan 11, 2017 at 1:13 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Tue, Sep 13, 2016 at 9:03 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sat, Sep 10, 2016 at 10:25 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Wed, Sep 7, 2016 at 1:37 AM, Eric Larson <larson.eric.d@gmail.com> wrote:
> My feeling is that having a clear leader in place is important, so I'm > also leaning away from the numpy model towards one where > responsibilities are more explicitly assigned. Exactly how to best > make > that assignment is still unclear to me.
+1 for BD(FL) / leader-style from me, too. I like Matthew's suggestion of the top 5 active folks discuss to see which of them are actually interested in taking on that role.
Thanks for the feedback everyone. Looks like everyone likes this suggestion so far, so we'll give that a try.
Hi all, I'm happy to report that we've worked this out. Pauli was our preferred candidate, and he has agreed to take up the role of BDFL!
<snip>
The main question I'd like to raise, is whether we really want a BDFL, as opposed to an elected projected leader.
I think a BDFL makes sense where there's one person who started the project, wrote most of the code (at least at some point in the project's history), has been in charge since the beginning, and is still very active. I think that does correspond to the situation for Linus / Linux; Guido / Python; and Fernando / IPython. I don't think we have anyone matching that description in Scipy.
On the other hand, I do think it's important to have a project leader, with final authority on the direction of the project, and who takes responsibility for the health of the project.
So, I propose, rather than have a BDFL, we have a system for choosing a leader,
Which is exactly how it worked this time --- using the system of your suggestion, https://mail.scipy.org/pipermail/scipy-dev/2016-September/021476.html
say every 4 years, where we may or may not have limits on the number of consecutive terms.
While I agree that this model is better in the vast majority of situations, it feels to be a bit of over-engineering for scipy.
We can use that 4 year cycle to make sure we're reconsidering the direction of the project regularly, and thinking about where we could improve, and where we might be messing up. It provides a natural way to give people a rest from the job, if they want one. If one leader steps back, and sees another leader doing something better than they did, they can learn from that when they next have a leadership term.
I agree it's worth it to periodically sit down and think about the direction of the project. I'm not sure though there is benefit in tying this up to a machinery of fixed-time leadership terms, holding formal elections and so on.
Of course that requires some formalization, but I think it's a considerably better system than the BDFL, for our case.
It seems to me that the effort needed to formalize it is not worth the benefit, specifically in our case.
Well - as a broader community, I think we'll have to do this anyway. For example, I know that Stefan vdW wants to set up this model for scikit-image. I am sure he'd be happy to help draft it, I know I would. Maybe we could do that in relation to this PR, making sure that we set some reasonable time limit for getting it done, say 3 weeks. Cheers, Matthew
On Fri, Jan 13, 2017 at 6:32 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Fri, Jan 13, 2017 at 3:24 PM, Evgeni Burovski <evgeny.burovskiy@gmail.com> wrote:
On Fri, Jan 13, 2017 at 8:22 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Wed, Jan 11, 2017 at 1:13 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Tue, Sep 13, 2016 at 9:03 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sat, Sep 10, 2016 at 10:25 AM, Ralf Gommers <
ralf.gommers@gmail.com>
wrote:
On Wed, Sep 7, 2016 at 1:37 AM, Eric Larson <larson.eric.d@gmail.com
wrote: > > >> My feeling is that having a clear leader in place is important, so I'm >> also leaning away from the numpy model towards one where >> responsibilities are more explicitly assigned. Exactly how to best >> make >> that assignment is still unclear to me. > > > +1 for BD(FL) / leader-style from me, too. I like Matthew's suggestion > of the top 5 active folks discuss to see which of them are actually > interested in taking on that role.
Thanks for the feedback everyone. Looks like everyone likes this suggestion so far, so we'll give that a try.
Hi all, I'm happy to report that we've worked this out. Pauli was our preferred candidate, and he has agreed to take up the role of BDFL!
<snip>
The main question I'd like to raise, is whether we really want a BDFL, as opposed to an elected projected leader.
I think a BDFL makes sense where there's one person who started the project, wrote most of the code (at least at some point in the project's history), has been in charge since the beginning, and is still very active. I think that does correspond to the situation for Linus / Linux; Guido / Python; and Fernando / IPython. I don't think we have anyone matching that description in Scipy.
On the other hand, I do think it's important to have a project leader, with final authority on the direction of the project, and who takes responsibility for the health of the project.
So, I propose, rather than have a BDFL, we have a system for choosing a leader,
Which is exactly how it worked this time --- using the system of your suggestion, https://mail.scipy.org/pipermail/scipy-dev/2016- September/021476.html
say every 4 years, where we may or may not have limits on the number of consecutive terms.
While I agree that this model is better in the vast majority of situations, it feels to be a bit of over-engineering for scipy.
We can use that 4 year cycle to make sure we're reconsidering the direction of the project regularly, and thinking about where we could improve, and where we might be messing up. It provides a natural way to give people a rest from the job, if they want one. If one leader steps back, and sees another leader doing something better than they did, they can learn from that when they next have a leadership term.
I agree it's worth it to periodically sit down and think about the direction of the project. I'm not sure though there is benefit in tying this up to a machinery of fixed-time leadership terms, holding formal elections and so on.
Of course that requires some formalization, but I think it's a considerably better system than the BDFL, for our case.
It seems to me that the effort needed to formalize it is not worth the benefit, specifically in our case.
Well - as a broader community, I think we'll have to do this anyway. For example, I know that Stefan vdW wants to set up this model for scikit-image. I am sure he'd be happy to help draft it, I know I would. Maybe we could do that in relation to this PR, making sure that we set some reasonable time limit for getting it done, say 3 weeks.
I like the stability and continuity that a known BDFL offers and signals, and wouldn't want a formalized voting system where somebody might try to game the system and get the majority of "electoral votes". Either scheduled elections are redundant because of a consensus or they create additional stress if you need to get x%. Josef "Make Scipy great again"
Cheers,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org https://mail.scipy.org/mailman/listinfo/scipy-dev
On Fri, Jan 13, 2017 at 3:32 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Fri, Jan 13, 2017 at 3:24 PM, Evgeni Burovski <evgeny.burovskiy@gmail.com> wrote:
On Fri, Jan 13, 2017 at 8:22 PM, Matthew Brett <matthew.brett@gmail.com> wrote: [...]
Of course that requires some formalization, but I think it's a considerably better system than the BDFL, for our case.
It seems to me that the effort needed to formalize it is not worth the benefit, specifically in our case.
Well - as a broader community, I think we'll have to do this anyway. For example, I know that Stefan vdW wants to set up this model for scikit-image. I am sure he'd be happy to help draft it, I know I would. Maybe we could do that in relation to this PR, making sure that we set some reasonable time limit for getting it done, say 3 weeks.
It's still the case that this is a novel social organization you invented that AFAICT has never been tested by any F/OSS project, and directly goes against the F/OSS community's hard-won cultural knowledge about what kinds of organizations work well (see e.g. [1]). Now- these are not necessarily bad things! Our community is legitimately different than a "traditional" group of F/OSS developers in a variety of ways, and less encultured to the "traditional" way of doing things. And social experimentation is great -- how else can we find better ways to live? While there's a lot of wisdom and experience in Karl Fogel's book, it's surely not the final word. But... we should also be realistic that when someone shows up saying "hey I've worked out a better method of social organization based on first principles and thinking really hard, it'll 100% definitely be awesome", then historically it *usually* doesn't quite work out so nicely as promised. And it's often difficult to effectively do this kind of experimentation at the same time as doing the actual work of like, developing software. "Choose boring technology" [2] applies to social technology too. If scikit-image is set on doing this, maybe the pragmatic thing to do is wait and see how it works out for them? I've seen zero appetite from anyone else on this list for elections and such. -n [1] http://producingoss.com/en/producingoss.html#social-infrastructure [2] http://mcfunley.com/choose-boring-technology -- Nathaniel J. Smith -- https://vorpus.org
Hi, On Fri, Jan 13, 2017 at 4:15 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Jan 13, 2017 at 3:32 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Fri, Jan 13, 2017 at 3:24 PM, Evgeni Burovski <evgeny.burovskiy@gmail.com> wrote:
On Fri, Jan 13, 2017 at 8:22 PM, Matthew Brett <matthew.brett@gmail.com> wrote: [...]
Of course that requires some formalization, but I think it's a considerably better system than the BDFL, for our case.
It seems to me that the effort needed to formalize it is not worth the benefit, specifically in our case.
Well - as a broader community, I think we'll have to do this anyway. For example, I know that Stefan vdW wants to set up this model for scikit-image. I am sure he'd be happy to help draft it, I know I would. Maybe we could do that in relation to this PR, making sure that we set some reasonable time limit for getting it done, say 3 weeks.
It's still the case that this is a novel social organization you invented that AFAICT has never been tested by any F/OSS project, and directly goes against the F/OSS community's hard-won cultural knowledge about what kinds of organizations work well (see e.g. [1]). Now- these are not necessarily bad things! Our community is legitimately different than a "traditional" group of F/OSS developers in a variety of ways, and less encultured to the "traditional" way of doing things. And social experimentation is great -- how else can we find better ways to live? While there's a lot of wisdom and experience in Karl Fogel's book, it's surely not the final word.
But... we should also be realistic that when someone shows up saying "hey I've worked out a better method of social organization based on first principles and thinking really hard, it'll 100% definitely be awesome", then historically it *usually* doesn't quite work out so nicely as promised. And it's often difficult to effectively do this kind of experimentation at the same time as doing the actual work of like, developing software. "Choose boring technology" [2] applies to social technology too.
* I agree with boring technology, but I doubt you're really arguing that choosing a leader at regular intervals is novel in open source or elsewhere. Debian is an obvious example [1]; * I don't know if an 'election' is the right method of choosing someone, that's really up for debate. Obviously an election is a very standard way of doing that; * I don't personally know of a BDFL system working well in the absence of the criteria I put above, but it would certainly be useful to have a look at a few examples. Can you suggest a few to consider?
If scikit-image is set on doing this, maybe the pragmatic thing to do is wait and see how it works out for them? I've seen zero appetite from anyone else on this list for elections and such.
I think your idea here is the BDFL is low risk and choosing a leader is high risk, but it seems to me that both have risks, and that the best way of assessing the relative risks is to consider and refine a couple of concrete proposals, with discussion of prior experience, where applicable. For the appetite thing, you are probably referring to the nervous atmosphere that surrounds any discussion of governance, which is presumably due to the strong reactions against any such discussion in the past. I'm sure you'd agree that that 'get it over with as quickly as possible' is not the best way to come to a good solution. Having said that, if Ralf and / or Pauli do not have much interest in this topic, discussion will quickly become futile and counterproductive, and we will have to stop quickly to avoid making a mess. Cheers, Matthew [1] https://www.debian.org/devel/leader
On Fri, Jan 13, 2017 at 8:01 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Fri, Jan 13, 2017 at 4:15 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Jan 13, 2017 at 3:32 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Fri, Jan 13, 2017 at 3:24 PM, Evgeni Burovski <evgeny.burovskiy@gmail.com> wrote:
On Fri, Jan 13, 2017 at 8:22 PM, Matthew Brett < matthew.brett@gmail.com> wrote: [...]
Of course that requires some formalization, but I think it's a considerably better system than the BDFL, for our case.
It seems to me that the effort needed to formalize it is not worth the benefit, specifically in our case.
Well - as a broader community, I think we'll have to do this anyway. For example, I know that Stefan vdW wants to set up this model for scikit-image. I am sure he'd be happy to help draft it, I know I would. Maybe we could do that in relation to this PR, making sure that we set some reasonable time limit for getting it done, say 3 weeks.
It's still the case that this is a novel social organization you invented that AFAICT has never been tested by any F/OSS project, and directly goes against the F/OSS community's hard-won cultural knowledge about what kinds of organizations work well (see e.g. [1]). Now- these are not necessarily bad things! Our community is legitimately different than a "traditional" group of F/OSS developers in a variety of ways, and less encultured to the "traditional" way of doing things. And social experimentation is great -- how else can we find better ways to live? While there's a lot of wisdom and experience in Karl Fogel's book, it's surely not the final word.
But... we should also be realistic that when someone shows up saying "hey I've worked out a better method of social organization based on first principles and thinking really hard, it'll 100% definitely be awesome", then historically it *usually* doesn't quite work out so nicely as promised. And it's often difficult to effectively do this kind of experimentation at the same time as doing the actual work of like, developing software. "Choose boring technology" [2] applies to social technology too.
* I agree with boring technology, but I doubt you're really arguing that choosing a leader at regular intervals is novel in open source or elsewhere. Debian is an obvious example [1]; * I don't know if an 'election' is the right method of choosing someone, that's really up for debate. Obviously an election is a very standard way of doing that; * I don't personally know of a BDFL system working well in the absence of the criteria I put above, but it would certainly be useful to have a look at a few examples. Can you suggest a few to consider?
If scikit-image is set on doing this, maybe the pragmatic thing to do is wait and see how it works out for them? I've seen zero appetite from anyone else on this list for elections and such.
I think your idea here is the BDFL is low risk and choosing a leader is high risk, but it seems to me that both have risks, and that the best way of assessing the relative risks is to consider and refine a couple of concrete proposals, with discussion of prior experience, where applicable.
For the appetite thing, you are probably referring to the nervous atmosphere that surrounds any discussion of governance, which is presumably due to the strong reactions against any such discussion in the past. I'm sure you'd agree that that 'get it over with as quickly as possible' is not the best way to come to a good solution. Having said that, if Ralf and / or Pauli do not have much interest in this topic, discussion will quickly become futile and counterproductive, and we will have to stop quickly to avoid making a mess.
Cheers,
Matthew
One big difference between Debian and scipy is the scale. There are 21 members on the scipy steering council and just a few of them that cover a larger part of scipy. The BDFL is a combination of technical council and a bit of a president/Project Leader (internal and external representation) in Debian terms, AFAIU. aside: It looks like the Steering Council is also the constitutional assembly that could switch from Benevolent Dictatorship to Democracy. "Update policy documents such as this one." At least this induced me to really read Ralf's PR, instead of just superficially skimming it. Overall, and given the composition and recruiting of scipy contributors and maintainers, I don't see much difference if the technical council is a BDFL or a BDF5YR (5 year renewable). Does Pauli feel forced to stick with scipy because he is BDFL? Does Evgeni (for example) put in more work than he already does because he wants to be elected the next BDF5YR? Do we get 25 new institutional contributors and council members so they can take over the BDF5YR role? or Does live go on as usual? Josef
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org https://mail.scipy.org/mailman/listinfo/scipy-dev
On Fri, Jan 13, 2017 at 5:01 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Fri, Jan 13, 2017 at 4:15 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Jan 13, 2017 at 3:32 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Fri, Jan 13, 2017 at 3:24 PM, Evgeni Burovski <evgeny.burovskiy@gmail.com> wrote:
On Fri, Jan 13, 2017 at 8:22 PM, Matthew Brett <matthew.brett@gmail.com> wrote: [...]
Of course that requires some formalization, but I think it's a considerably better system than the BDFL, for our case.
It seems to me that the effort needed to formalize it is not worth the benefit, specifically in our case.
Well - as a broader community, I think we'll have to do this anyway. For example, I know that Stefan vdW wants to set up this model for scikit-image. I am sure he'd be happy to help draft it, I know I would. Maybe we could do that in relation to this PR, making sure that we set some reasonable time limit for getting it done, say 3 weeks.
It's still the case that this is a novel social organization you invented that AFAICT has never been tested by any F/OSS project, and directly goes against the F/OSS community's hard-won cultural knowledge about what kinds of organizations work well (see e.g. [1]). Now- these are not necessarily bad things! Our community is legitimately different than a "traditional" group of F/OSS developers in a variety of ways, and less encultured to the "traditional" way of doing things. And social experimentation is great -- how else can we find better ways to live? While there's a lot of wisdom and experience in Karl Fogel's book, it's surely not the final word.
But... we should also be realistic that when someone shows up saying "hey I've worked out a better method of social organization based on first principles and thinking really hard, it'll 100% definitely be awesome", then historically it *usually* doesn't quite work out so nicely as promised. And it's often difficult to effectively do this kind of experimentation at the same time as doing the actual work of like, developing software. "Choose boring technology" [2] applies to social technology too.
* I agree with boring technology, but I doubt you're really arguing that choosing a leader at regular intervals is novel in open source or elsewhere.
I'm arguing exactly that. (In open source, obviously; scipy is not a nation-state.)
Debian is an obvious example [1];
But the Debian Project Leader is *nothing at all* like a BDFL. In fact their powers are extraordinarily limited; mostly it's just "convince people to do stuff by talking to them" (i.e. "exercising leadership") and "serve as a project figurehead". Which is what your links says! They explicitly *cannot* make decisions about the technical direction of the project; in the Debian system that power is delegated in a complicated way to individual maintainers, mailing list consensus, the CTTE, and GRs. If I seem frustrated in discussing these topics with you, then this is why :-(. As is probably obvious to everyone, I actually love geeking out about this kind of thing! But when you make such misleading and hand-wavy arguments it feels lazy, like you're more interested in vague in-principle discussions than in actually trying to put together a real system that can be implemented and help the project move on and accomplish its real goals. I know that's not your intention and I'm sorry if that sounds harsh. But at this point I'm having trouble seeing how your comments are helping move things forward in any kind of practical way.
* I don't know if an 'election' is the right method of choosing someone, that's really up for debate. Obviously an election is a very standard way of doing that; * I don't personally know of a BDFL system working well in the absence of the criteria I put above, but it would certainly be useful to have a look at a few examples. Can you suggest a few to consider?
If scikit-image is set on doing this, maybe the pragmatic thing to do is wait and see how it works out for them? I've seen zero appetite from anyone else on this list for elections and such.
I think your idea here is the BDFL is low risk and choosing a leader is high risk, but it seems to me that both have risks, and that the best way of assessing the relative risks is to consider and refine a couple of concrete proposals, with discussion of prior experience, where applicable.
For the appetite thing, you are probably referring to the nervous atmosphere that surrounds any discussion of governance, which is presumably due to the strong reactions against any such discussion in the past. I'm sure you'd agree that that 'get it over with as quickly as possible' is not the best way to come to a good solution. Having said that, if Ralf and / or Pauli do not have much interest in this topic, discussion will quickly become futile and counterproductive, and we will have to stop quickly to avoid making a mess.
I'm more referring about the part where scipy *has* a governance document now that seems perfectly workable. It's not identical to the one I would have written, but so what, there are lots of workable models and this looks like one of them. I'm not seeing folks jumping in eager to redo that process for unclear benefits. -n -- Nathaniel J. Smith -- https://vorpus.org
On Fri, Jan 13, 2017 at 7:38 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Jan 13, 2017 at 5:01 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Fri, Jan 13, 2017 at 4:15 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Jan 13, 2017 at 3:32 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Fri, Jan 13, 2017 at 3:24 PM, Evgeni Burovski <evgeny.burovskiy@gmail.com> wrote:
On Fri, Jan 13, 2017 at 8:22 PM, Matthew Brett <matthew.brett@gmail.com> wrote: [...]
Of course that requires some formalization, but I think it's a considerably better system than the BDFL, for our case.
It seems to me that the effort needed to formalize it is not worth the benefit, specifically in our case.
Well - as a broader community, I think we'll have to do this anyway. For example, I know that Stefan vdW wants to set up this model for scikit-image. I am sure he'd be happy to help draft it, I know I would. Maybe we could do that in relation to this PR, making sure that we set some reasonable time limit for getting it done, say 3 weeks.
It's still the case that this is a novel social organization you invented that AFAICT has never been tested by any F/OSS project, and directly goes against the F/OSS community's hard-won cultural knowledge about what kinds of organizations work well (see e.g. [1]). Now- these are not necessarily bad things! Our community is legitimately different than a "traditional" group of F/OSS developers in a variety of ways, and less encultured to the "traditional" way of doing things. And social experimentation is great -- how else can we find better ways to live? While there's a lot of wisdom and experience in Karl Fogel's book, it's surely not the final word.
But... we should also be realistic that when someone shows up saying "hey I've worked out a better method of social organization based on first principles and thinking really hard, it'll 100% definitely be awesome", then historically it *usually* doesn't quite work out so nicely as promised. And it's often difficult to effectively do this kind of experimentation at the same time as doing the actual work of like, developing software. "Choose boring technology" [2] applies to social technology too.
* I agree with boring technology, but I doubt you're really arguing that choosing a leader at regular intervals is novel in open source or elsewhere.
I'm arguing exactly that. (In open source, obviously; scipy is not a nation-state.)
or an arm of local government or a school or a ...
Debian is an obvious example [1];
But the Debian Project Leader is *nothing at all* like a BDFL. In fact their powers are extraordinarily limited; mostly it's just "convince people to do stuff by talking to them" (i.e. "exercising leadership") and "serve as a project figurehead". Which is what your links says! They explicitly *cannot* make decisions about the technical direction of the project; in the Debian system that power is delegated in a complicated way to individual maintainers, mailing list consensus, the CTTE, and GRs.
Look - please - calm down. We can have serious calm discussion about this. Sure, Debian uses it's leader in a different way, as could we, I don't think we have to bring out the shotguns here.
If I seem frustrated in discussing these topics with you, then this is why :-(. As is probably obvious to everyone, I actually love geeking out about this kind of thing! But when you make such misleading and hand-wavy arguments it feels lazy, like you're more interested in vague in-principle discussions than in actually trying to put together a real system that can be implemented and help the project move on and accomplish its real goals.
So - this is really very frustrating. I just proposed writing up a document, and comparing to the current one, in a short and reasonable period. I told you that Stefan, who's credentials as a project leader can't reasonably be challenged, is also thinking hard about this. It's terribly tiring to have to justify my good faith every time we have this discussion. I know that's not your intention and I'm
sorry if that sounds harsh. But at this point I'm having trouble seeing how your comments are helping move things forward in any kind of practical way.
I don't know about harsh, but it certainly sounds impatient and patronizing. Incidentally, I had hoped you'd provide a couple of examples of BDFL projects where the BDFL was not the founder / major author. Maybe the discussion could get better if we covered stuff like that.
* I don't know if an 'election' is the right method of choosing someone, that's really up for debate. Obviously an election is a very standard way of doing that; * I don't personally know of a BDFL system working well in the absence of the criteria I put above, but it would certainly be useful to have a look at a few examples. Can you suggest a few to consider?
If scikit-image is set on doing this, maybe the pragmatic thing to do is wait and see how it works out for them? I've seen zero appetite from anyone else on this list for elections and such.
I think your idea here is the BDFL is low risk and choosing a leader is high risk, but it seems to me that both have risks, and that the best way of assessing the relative risks is to consider and refine a couple of concrete proposals, with discussion of prior experience, where applicable.
For the appetite thing, you are probably referring to the nervous atmosphere that surrounds any discussion of governance, which is presumably due to the strong reactions against any such discussion in the past. I'm sure you'd agree that that 'get it over with as quickly as possible' is not the best way to come to a good solution. Having said that, if Ralf and / or Pauli do not have much interest in this topic, discussion will quickly become futile and counterproductive, and we will have to stop quickly to avoid making a mess.
I'm more referring about the part where scipy *has* a governance document now that seems perfectly workable. It's not identical to the one I would have written, but so what, there are lots of workable models and this looks like one of them. I'm not seeing folks jumping in eager to redo that process for unclear benefits.
I had hoped to cover that in my previous email. In practice, if Ralf and Pauli do not want to discuss this, this discussion is pointless, and we should stop this right now. However, contrary to your apparent assumption, I did not start this discussion to annoy, confuse or impress, I started it in the hope of finding the best possible model for Scipy governance, Best, Matthew
On Fri, Jan 13, 2017 at 10:57 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
On Fri, Jan 13, 2017 at 5:01 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Fri, Jan 13, 2017 at 4:15 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Jan 13, 2017 at 3:32 PM, Matthew Brett < matthew.brett@gmail.com> wrote:
Hi,
On Fri, Jan 13, 2017 at 3:24 PM, Evgeni Burovski <evgeny.burovskiy@gmail.com> wrote:
On Fri, Jan 13, 2017 at 8:22 PM, Matthew Brett < matthew.brett@gmail.com> wrote: [...] > Of course that requires some formalization, but I think it's a > considerably better system than the BDFL, for our case.
It seems to me that the effort needed to formalize it is not worth
On Fri, Jan 13, 2017 at 7:38 PM, Nathaniel Smith <njs@pobox.com> wrote: the
benefit, specifically in our case.
Well - as a broader community, I think we'll have to do this anyway. For example, I know that Stefan vdW wants to set up this model for scikit-image. I am sure he'd be happy to help draft it, I know I would. Maybe we could do that in relation to this PR, making sure that we set some reasonable time limit for getting it done, say 3 weeks.
It's still the case that this is a novel social organization you invented that AFAICT has never been tested by any F/OSS project, and directly goes against the F/OSS community's hard-won cultural knowledge about what kinds of organizations work well (see e.g. [1]). Now- these are not necessarily bad things! Our community is legitimately different than a "traditional" group of F/OSS developers in a variety of ways, and less encultured to the "traditional" way of doing things. And social experimentation is great -- how else can we find better ways to live? While there's a lot of wisdom and experience in Karl Fogel's book, it's surely not the final word.
But... we should also be realistic that when someone shows up saying "hey I've worked out a better method of social organization based on first principles and thinking really hard, it'll 100% definitely be awesome", then historically it *usually* doesn't quite work out so nicely as promised. And it's often difficult to effectively do this kind of experimentation at the same time as doing the actual work of like, developing software. "Choose boring technology" [2] applies to social technology too.
* I agree with boring technology, but I doubt you're really arguing that choosing a leader at regular intervals is novel in open source or elsewhere.
I'm arguing exactly that. (In open source, obviously; scipy is not a nation-state.)
or an arm of local government or a school or a ...
Debian is an obvious example [1];
But the Debian Project Leader is *nothing at all* like a BDFL. In fact their powers are extraordinarily limited; mostly it's just "convince people to do stuff by talking to them" (i.e. "exercising leadership") and "serve as a project figurehead". Which is what your links says! They explicitly *cannot* make decisions about the technical direction of the project; in the Debian system that power is delegated in a complicated way to individual maintainers, mailing list consensus, the CTTE, and GRs.
Look - please - calm down. We can have serious calm discussion about this. Sure, Debian uses it's leader in a different way, as could we, I don't think we have to bring out the shotguns here.
If I seem frustrated in discussing these topics with you, then this is why :-(. As is probably obvious to everyone, I actually love geeking out about this kind of thing! But when you make such misleading and hand-wavy arguments it feels lazy, like you're more interested in vague in-principle discussions than in actually trying to put together a real system that can be implemented and help the project move on and accomplish its real goals.
So - this is really very frustrating. I just proposed writing up a document, and comparing to the current one, in a short and reasonable period. I told you that Stefan, who's credentials as a project leader can't reasonably be challenged, is also thinking hard about this. It's terribly tiring to have to justify my good faith every time we have this discussion.
I know that's not your intention and I'm
sorry if that sounds harsh. But at this point I'm having trouble seeing how your comments are helping move things forward in any kind of practical way.
I don't know about harsh, but it certainly sounds impatient and patronizing.
Incidentally, I had hoped you'd provide a couple of examples of BDFL projects where the BDFL was not the founder / major author. Maybe the discussion could get better if we covered stuff like that.
The example is scipy. Pauli has been the implied BDFL for years with Ralf as "Assistant BDFL". Didn't matplotlib and pandas not also have transition to new de-facto BDFLs? I once mentioned in a related mailing list discussion that we should just codify the status quo which has worked and is working pretty well. Two of the longest scipy github discussions I have been involved with https://github.com/scipy/scipy/pull/448 compromise implemented https://github.com/scipy/scipy/issues/3129 rejected, full solution about 2 years later (In scipy stats I'm glad to leave all controversial decisions to Evgeni and Ralf, outside those related to statistical theory.)
* I don't know if an 'election' is the right method of choosing someone, that's really up for debate. Obviously an election is a very standard way of doing that; * I don't personally know of a BDFL system working well in the absence of the criteria I put above, but it would certainly be useful to have a look at a few examples. Can you suggest a few to consider?
If scikit-image is set on doing this, maybe the pragmatic thing to do is wait and see how it works out for them? I've seen zero appetite from anyone else on this list for elections and such.
I think your idea here is the BDFL is low risk and choosing a leader is high risk, but it seems to me that both have risks, and that the best way of assessing the relative risks is to consider and refine a couple of concrete proposals, with discussion of prior experience, where applicable.
For the appetite thing, you are probably referring to the nervous atmosphere that surrounds any discussion of governance, which is presumably due to the strong reactions against any such discussion in the past. I'm sure you'd agree that that 'get it over with as quickly as possible' is not the best way to come to a good solution. Having said that, if Ralf and / or Pauli do not have much interest in this topic, discussion will quickly become futile and counterproductive, and we will have to stop quickly to avoid making a mess.
I'm more referring about the part where scipy *has* a governance document now that seems perfectly workable. It's not identical to the one I would have written, but so what, there are lots of workable models and this looks like one of them. I'm not seeing folks jumping in eager to redo that process for unclear benefits.
I had hoped to cover that in my previous email. In practice, if Ralf and Pauli do not want to discuss this, this discussion is pointless, and we should stop this right now. However, contrary to your apparent assumption, I did not start this discussion to annoy, confuse or impress, I started it in the hope of finding the best possible model for Scipy governance,
You are waiting for a pronouncement from our BDFLs? Josef
Best,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org https://mail.scipy.org/mailman/listinfo/scipy-dev
Hi, On Fri, Jan 13, 2017 at 8:47 PM, <josef.pktd@gmail.com> wrote:
On Fri, Jan 13, 2017 at 10:57 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
On Fri, Jan 13, 2017 at 7:38 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Jan 13, 2017 at 5:01 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Fri, Jan 13, 2017 at 4:15 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Jan 13, 2017 at 3:32 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Fri, Jan 13, 2017 at 3:24 PM, Evgeni Burovski <evgeny.burovskiy@gmail.com> wrote: > On Fri, Jan 13, 2017 at 8:22 PM, Matthew Brett > <matthew.brett@gmail.com> wrote: [...] >> Of course that requires some formalization, but I think it's a >> considerably better system than the BDFL, for our case. > > It seems to me that the effort needed to formalize it is not worth > the > benefit, specifically in our case.
Well - as a broader community, I think we'll have to do this anyway. For example, I know that Stefan vdW wants to set up this model for scikit-image. I am sure he'd be happy to help draft it, I know I would. Maybe we could do that in relation to this PR, making sure that we set some reasonable time limit for getting it done, say 3 weeks.
It's still the case that this is a novel social organization you invented that AFAICT has never been tested by any F/OSS project, and directly goes against the F/OSS community's hard-won cultural knowledge about what kinds of organizations work well (see e.g. [1]). Now- these are not necessarily bad things! Our community is legitimately different than a "traditional" group of F/OSS developers in a variety of ways, and less encultured to the "traditional" way of doing things. And social experimentation is great -- how else can we find better ways to live? While there's a lot of wisdom and experience in Karl Fogel's book, it's surely not the final word.
But... we should also be realistic that when someone shows up saying "hey I've worked out a better method of social organization based on first principles and thinking really hard, it'll 100% definitely be awesome", then historically it *usually* doesn't quite work out so nicely as promised. And it's often difficult to effectively do this kind of experimentation at the same time as doing the actual work of like, developing software. "Choose boring technology" [2] applies to social technology too.
* I agree with boring technology, but I doubt you're really arguing that choosing a leader at regular intervals is novel in open source or elsewhere.
I'm arguing exactly that. (In open source, obviously; scipy is not a nation-state.)
or an arm of local government or a school or a ...
Debian is an obvious example [1];
But the Debian Project Leader is *nothing at all* like a BDFL. In fact their powers are extraordinarily limited; mostly it's just "convince people to do stuff by talking to them" (i.e. "exercising leadership") and "serve as a project figurehead". Which is what your links says! They explicitly *cannot* make decisions about the technical direction of the project; in the Debian system that power is delegated in a complicated way to individual maintainers, mailing list consensus, the CTTE, and GRs.
Look - please - calm down. We can have serious calm discussion about this. Sure, Debian uses it's leader in a different way, as could we, I don't think we have to bring out the shotguns here.
If I seem frustrated in discussing these topics with you, then this is why :-(. As is probably obvious to everyone, I actually love geeking out about this kind of thing! But when you make such misleading and hand-wavy arguments it feels lazy, like you're more interested in vague in-principle discussions than in actually trying to put together a real system that can be implemented and help the project move on and accomplish its real goals.
So - this is really very frustrating. I just proposed writing up a document, and comparing to the current one, in a short and reasonable period. I told you that Stefan, who's credentials as a project leader can't reasonably be challenged, is also thinking hard about this. It's terribly tiring to have to justify my good faith every time we have this discussion.
I know that's not your intention and I'm
sorry if that sounds harsh. But at this point I'm having trouble seeing how your comments are helping move things forward in any kind of practical way.
I don't know about harsh, but it certainly sounds impatient and patronizing.
Incidentally, I had hoped you'd provide a couple of examples of BDFL projects where the BDFL was not the founder / major author. Maybe the discussion could get better if we covered stuff like that.
The example is scipy. Pauli has been the implied BDFL for years with Ralf as "Assistant BDFL".
I don't think we knew who was in charge of Scipy until the candidates discussed that a few months ago. Remember that the thing we're discussing is the FL in BDFL. I get the impression we Scipiers mostly agree that having a named leader is a good idea.
Didn't matplotlib and pandas not also have transition to new de-facto BDFLs?
Here are the Pandas governance docs : https://github.com/pandas-dev/pandas-governance . Of course Pandas is a young project, but it also has a founder and main author, making the BDFL a more obvious model. Matplotlib did just adopt a similar doc, where the nominated BDFL is not the founder, but they've only had their governance doc for six months or so, and so we haven't got any data yet on the FL part: https://github.com/matplotlib/governance/blob/master/governance.md
I once mentioned in a related mailing list discussion that we should just codify the status quo which has worked and is working pretty well.
Yes, right - it is working well - but the point of a governance document is to keep it working well for a long time. The value of the 4 year (or whatever) cycle is to have a chance to review whether things are still working well, and make changes if they are not.
Two of the longest scipy github discussions I have been involved with https://github.com/scipy/scipy/pull/448 compromise implemented https://github.com/scipy/scipy/issues/3129 rejected, full solution about 2 years later
(In scipy stats I'm glad to leave all controversial decisions to Evgeni and Ralf, outside those related to statistical theory.)
* I don't know if an 'election' is the right method of choosing someone, that's really up for debate. Obviously an election is a very standard way of doing that; * I don't personally know of a BDFL system working well in the absence of the criteria I put above, but it would certainly be useful to have a look at a few examples. Can you suggest a few to consider?
If scikit-image is set on doing this, maybe the pragmatic thing to do is wait and see how it works out for them? I've seen zero appetite from anyone else on this list for elections and such.
I think your idea here is the BDFL is low risk and choosing a leader is high risk, but it seems to me that both have risks, and that the best way of assessing the relative risks is to consider and refine a couple of concrete proposals, with discussion of prior experience, where applicable.
For the appetite thing, you are probably referring to the nervous atmosphere that surrounds any discussion of governance, which is presumably due to the strong reactions against any such discussion in the past. I'm sure you'd agree that that 'get it over with as quickly as possible' is not the best way to come to a good solution. Having said that, if Ralf and / or Pauli do not have much interest in this topic, discussion will quickly become futile and counterproductive, and we will have to stop quickly to avoid making a mess.
I'm more referring about the part where scipy *has* a governance document now that seems perfectly workable. It's not identical to the one I would have written, but so what, there are lots of workable models and this looks like one of them. I'm not seeing folks jumping in eager to redo that process for unclear benefits.
I had hoped to cover that in my previous email. In practice, if Ralf and Pauli do not want to discuss this, this discussion is pointless, and we should stop this right now. However, contrary to your apparent assumption, I did not start this discussion to annoy, confuse or impress, I started it in the hope of finding the best possible model for Scipy governance,
You are waiting for a pronouncement from our BDFLs?
From our de-facto leaders, yes. When the conversation veers off the content and onto the motivations or personal qualities of the participants, the only way of fixing that, is for someone with authority to intervene, calm the discussion down, and make space for the discussion to continue without rancor. If that doesn't happen, then the discussion is useless because there's no space to work out the ideas.
Cheers, Matthew
On Sat, Jan 14, 2017 at 3:34 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Fri, Jan 13, 2017 at 8:47 PM, <josef.pktd@gmail.com> wrote:
On Fri, Jan 13, 2017 at 10:57 PM, Matthew Brett <matthew.brett@gmail.com
wrote:
On Fri, Jan 13, 2017 at 7:38 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Jan 13, 2017 at 5:01 PM, Matthew Brett <
matthew.brett@gmail.com>
wrote:
Hi,
On Fri, Jan 13, 2017 at 4:15 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Jan 13, 2017 at 3:32 PM, Matthew Brett <matthew.brett@gmail.com> wrote: > Hi, > > On Fri, Jan 13, 2017 at 3:24 PM, Evgeni Burovski > <evgeny.burovskiy@gmail.com> wrote: >> On Fri, Jan 13, 2017 at 8:22 PM, Matthew Brett >> <matthew.brett@gmail.com> wrote: [...] >>> Of course that requires some formalization, but I think it's a >>> considerably better system than the BDFL, for our case. >> >> It seems to me that the effort needed to formalize it is not worth >> the >> benefit, specifically in our case. > > Well - as a broader community, I think we'll have to do this anyway. > For example, I know that Stefan vdW wants to set up this model for > scikit-image. I am sure he'd be happy to help draft it, I know I > would. Maybe we could do that in relation to this PR, making sure > that we set some reasonable time limit for getting it done, say 3 > weeks.
It's still the case that this is a novel social organization you invented that AFAICT has never been tested by any F/OSS project, and directly goes against the F/OSS community's hard-won cultural knowledge about what kinds of organizations work well (see e.g. [1]). Now- these are not necessarily bad things! Our community is legitimately different than a "traditional" group of F/OSS developers in a variety of ways, and less encultured to the "traditional" way of doing things. And social experimentation is great -- how else can we find better ways to live? While there's a lot of wisdom and experience in Karl Fogel's book, it's surely not the final word.
But... we should also be realistic that when someone shows up saying "hey I've worked out a better method of social organization based on first principles and thinking really hard, it'll 100% definitely be awesome", then historically it *usually* doesn't quite work out so nicely as promised. And it's often difficult to effectively do this kind of experimentation at the same time as doing the actual work of like, developing software. "Choose boring technology" [2] applies to social technology too.
* I agree with boring technology, but I doubt you're really arguing that choosing a leader at regular intervals is novel in open source or elsewhere.
I'm arguing exactly that. (In open source, obviously; scipy is not a nation-state.)
or an arm of local government or a school or a ...
Debian is an obvious example [1];
But the Debian Project Leader is *nothing at all* like a BDFL. In fact their powers are extraordinarily limited; mostly it's just "convince people to do stuff by talking to them" (i.e. "exercising leadership") and "serve as a project figurehead". Which is what your links says! They explicitly *cannot* make decisions about the technical direction of the project; in the Debian system that power is delegated in a complicated way to individual maintainers, mailing list consensus, the CTTE, and GRs.
Look - please - calm down. We can have serious calm discussion about this. Sure, Debian uses it's leader in a different way, as could we, I don't think we have to bring out the shotguns here.
If I seem frustrated in discussing these topics with you, then this is why :-(. As is probably obvious to everyone, I actually love geeking out about this kind of thing! But when you make such misleading and hand-wavy arguments it feels lazy, like you're more interested in vague in-principle discussions than in actually trying to put together a real system that can be implemented and help the project move on and accomplish its real goals.
So - this is really very frustrating. I just proposed writing up a document, and comparing to the current one, in a short and reasonable period. I told you that Stefan, who's credentials as a project leader can't reasonably be challenged, is also thinking hard about this. It's terribly tiring to have to justify my good faith every time we have this discussion.
I know that's not your intention and I'm
sorry if that sounds harsh. But at this point I'm having trouble seeing how your comments are helping move things forward in any kind of practical way.
I don't know about harsh, but it certainly sounds impatient and patronizing.
Incidentally, I had hoped you'd provide a couple of examples of BDFL projects where the BDFL was not the founder / major author. Maybe the discussion could get better if we covered stuff like that.
The example is scipy. Pauli has been the implied BDFL for years with Ralf as "Assistant BDFL".
I don't think we knew who was in charge of Scipy until the candidates discussed that a few months ago.
It wasn't spelled out, but it was pretty clear how decisions were worked out. Actually, closer to the terms of Debian, Ralf was more the project lead in terms of pushing the "vision" and internal and external communication. Ralf also had the decision power of the release manager. Pauli has been the technical committee for final technical decisions. (Besides being also just regular contributors.)
Remember that the thing we're discussing is the FL in BDFL. I get the impression we Scipiers mostly agree that having a named leader is a good idea.
I consider FL to mean For Unlimited Time. He or she can always step down and go on to other things and appoint a successor or let the steering council choose a successor. For Life is a long time in open source development, and Guido is the only one I know of that lasted for a long time. The point of a BDFL is also that we have more trust in a person than in the political system. So we choose a BDFL instead of having to write a constitution that has to survive and make the system function for hundreds of years and for a few hundred million members. Josef
Didn't matplotlib and pandas not also have transition to new de-facto BDFLs?
Here are the Pandas governance docs : https://github.com/pandas-dev/pandas-governance . Of course Pandas is a young project, but it also has a founder and main author, making the BDFL a more obvious model.
Matplotlib did just adopt a similar doc, where the nominated BDFL is not the founder, but they've only had their governance doc for six months or so, and so we haven't got any data yet on the FL part:
https://github.com/matplotlib/governance/blob/master/governance.md
I once mentioned in a related mailing list discussion that we should just codify the status quo which has worked and is working pretty well.
Yes, right - it is working well - but the point of a governance document is to keep it working well for a long time. The value of the 4 year (or whatever) cycle is to have a chance to review whether things are still working well, and make changes if they are not.
Two of the longest scipy github discussions I have been involved with https://github.com/scipy/scipy/pull/448 compromise implemented https://github.com/scipy/scipy/issues/3129 rejected, full solution about 2 years later
(In scipy stats I'm glad to leave all controversial decisions to Evgeni and Ralf, outside those related to statistical theory.)
* I don't know if an 'election' is the right method of choosing someone, that's really up for debate. Obviously an election is a
very
standard way of doing that; * I don't personally know of a BDFL system working well in the absence of the criteria I put above, but it would certainly be useful to have a look at a few examples. Can you suggest a few to consider?
If scikit-image is set on doing this, maybe the pragmatic thing to do is wait and see how it works out for them? I've seen zero appetite from anyone else on this list for elections and such.
I think your idea here is the BDFL is low risk and choosing a leader is high risk, but it seems to me that both have risks, and that the best way of assessing the relative risks is to consider and refine a couple of concrete proposals, with discussion of prior experience, where applicable.
For the appetite thing, you are probably referring to the nervous atmosphere that surrounds any discussion of governance, which is presumably due to the strong reactions against any such discussion in the past. I'm sure you'd agree that that 'get it over with as quickly as possible' is not the best way to come to a good solution. Having said that, if Ralf and / or Pauli do not have much interest in this topic, discussion will quickly become futile and counterproductive, and we will have to stop quickly to avoid making a mess.
I'm more referring about the part where scipy *has* a governance document now that seems perfectly workable. It's not identical to the one I would have written, but so what, there are lots of workable models and this looks like one of them. I'm not seeing folks jumping in eager to redo that process for unclear benefits.
I had hoped to cover that in my previous email. In practice, if Ralf and Pauli do not want to discuss this, this discussion is pointless, and we should stop this right now. However, contrary to your apparent assumption, I did not start this discussion to annoy, confuse or impress, I started it in the hope of finding the best possible model for Scipy governance,
You are waiting for a pronouncement from our BDFLs?
From our de-facto leaders, yes. When the conversation veers off the content and onto the motivations or personal qualities of the participants, the only way of fixing that, is for someone with authority to intervene, calm the discussion down, and make space for the discussion to continue without rancor. If that doesn't happen, then the discussion is useless because there's no space to work out the ideas.
Cheers,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org https://mail.scipy.org/mailman/listinfo/scipy-dev
Fri, 13 Jan 2017 09:22:58 -0800, Matthew Brett kirjoitti: [clip]
So, I propose, rather than have a BDFL, we have a system for choosing a leader, say every 4 years, where we may or may not have limits on the number of consecutive terms.
I have no problem in principle with a model with a less permanent final decision authority role, or with more fallbacks for cases of serious conflict. However, I don't immediately know how to write down the details of such a model, and I think amendments would be best communicated via change suggestions in the PR. On the other hand, I must say I don't immediately see the value in making this role regularly rotating. This is because: (i) the person can step down at any time, and acting in good faith, will also listen to serious calls to do so, (ii) regular elections can generate unnecessary work and politics -- looking at the past 10 years of scipy, there has been little of this, and I believe this is for the best, (iii) this is more of a role for fallback decision making and less for a director/CEO. For those who did not read the linked document, the purpose of this particular role, despite the purposefully silly title, is mainly to enable the project to choose a direction in cases where consensus cannot be found. In the optimal case, this never happens, and there is no need to do anything. In particular, making decisions on the direction and vision for the project is in the hands of those on the steering council. Best regards, Pauli
Hi, Thanks for this reply - it's very helpful. On Sat, Jan 14, 2017 at 8:17 AM, Pauli Virtanen <pav@iki.fi> wrote:
Fri, 13 Jan 2017 09:22:58 -0800, Matthew Brett kirjoitti: [clip]
So, I propose, rather than have a BDFL, we have a system for choosing a leader, say every 4 years, where we may or may not have limits on the number of consecutive terms.
I have no problem in principle with a model with a less permanent final decision authority role, or with more fallbacks for cases of serious conflict. However, I don't immediately know how to write down the details of such a model, and I think amendments would be best communicated via change suggestions in the PR.
On the other hand, I must say I don't immediately see the value in making this role regularly rotating. This is because: (i) the person can step down at any time, and acting in good faith, will also listen to serious calls to do so, (ii) regular elections can generate unnecessary work and politics -- looking at the past 10 years of scipy, there has been little of this, and I believe this is for the best, (iii) this is more of a role for fallback decision making and less for a director/CEO.
Yes, right, we should certainly try to avoid adding a political process where it isn't needed. What do you think about the idea of having regular state-of-scipy reviews to make sure we're conscious about keeping on track, assessing risks, improving process? Cheers, Matthew
Hi, Sat, 14 Jan 2017 10:03:43 -0800, Matthew Brett kirjoitti: [clip]
What do you think about the idea of having regular state-of-scipy reviews to make sure we're conscious about keeping on track, assessing risks, improving process?
For the technical aspect, this sounds something like the Scipy roadmap (https://github.com/scipy/scipy/blob/master/doc/ROADMAP.rst.txt), and the discussion leading to it, in conferences and online in public. Something like regular prompts for discussion of technical and organisation roadmap could be useful. At minimum, this could be simply a (bi-?)yearly post on the mailing list, to remind to update the roadmap and to summarize / bring up / discuss any relevant organisation updates / issues in the preceding period. It could also be something more involved (suggestions welcome), but probably useful to keep in mind this is drawing from a limited time pool. Best, Pauli
On Sun, Jan 15, 2017 at 8:15 AM, Pauli Virtanen <pav@iki.fi> wrote: Interesting discussion so far!
Sat, 14 Jan 2017 10:03:43 -0800, Matthew Brett kirjoitti: [clip]
What do you think about the idea of having regular state-of-scipy reviews to make sure we're conscious about keeping on track, assessing risks, improving process?
For the technical aspect, this sounds something like the Scipy roadmap (https://github.com/scipy/scipy/blob/master/doc/ROADMAP.rst.txt), and the discussion leading to it, in conferences and online in public.
Something like regular prompts for discussion of technical and organisation roadmap could be useful. At minimum, this could be simply a (bi-?)yearly post on the mailing list, to remind to update the roadmap and to summarize / bring up / discuss any relevant organisation updates / issues in the preceding period.
I quite like this idea. Documents like a roadmap can easily go out of date if they're not actively maintained. Having a critical look at it once or twice a year will be helpful. Also +1 for adding some organizational items to it (I'm thinking CoC, FSA, etc. should have been on there). The list of people on the steering committee also needs to be updated with this kind of frequency. How about doing this around 1 January and 1 July every year? I'm not sensing a lot of enthusiasm for the fixed-term/election idea, so I'd gently suggest to not go down that path but instead look at the regular review above as an opportunity to bring up concerns regarding any aspect of our organisational structure (we can put in wording like that, PR welcome I'd say). Cheers, Ralf
On Mon, Jan 16, 2017 at 3:01 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
How about doing this around 1 January and 1 July every year?
Those dates fall during times when many people are traveling or otherwise not responsive. What about phase-shifting 3 months to April 1st / October 1st?
Mon, 16 Jan 2017 11:35:30 -0600, CJ Carey kirjoitti:
On Mon, Jan 16, 2017 at 3:01 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
How about doing this around 1 January and 1 July every year?
Those dates fall during times when many people are traveling or otherwise not responsive. What about phase-shifting 3 months to April 1st / October 1st?
Not that important, but now that we are optimizing this, I would push it a bit forward to eg. Apr 20 and Oct 20 to avoid beginning of academic semesters. Pauli
On Tue, Jan 17, 2017 at 9:09 AM, Pauli Virtanen <pav@iki.fi> wrote:
Mon, 16 Jan 2017 11:35:30 -0600, CJ Carey kirjoitti:
On Mon, Jan 16, 2017 at 3:01 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
How about doing this around 1 January and 1 July every year?
Those dates fall during times when many people are traveling or otherwise not responsive. What about phase-shifting 3 months to April 1st / October 1st?
Not that important, but now that we are optimizing this, I would push it a bit forward to eg. Apr 20 and Oct 20 to avoid beginning of academic semesters.
Sounds good, will add to the PR. We can micro-optimize there if needed:) Ralf
Hi, On Mon, Jan 16, 2017 at 1:01 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sun, Jan 15, 2017 at 8:15 AM, Pauli Virtanen <pav@iki.fi> wrote:
Interesting discussion so far!
Sat, 14 Jan 2017 10:03:43 -0800, Matthew Brett kirjoitti: [clip]
What do you think about the idea of having regular state-of-scipy reviews to make sure we're conscious about keeping on track, assessing risks, improving process?
For the technical aspect, this sounds something like the Scipy roadmap (https://github.com/scipy/scipy/blob/master/doc/ROADMAP.rst.txt), and the discussion leading to it, in conferences and online in public.
Something like regular prompts for discussion of technical and organisation roadmap could be useful. At minimum, this could be simply a (bi-?)yearly post on the mailing list, to remind to update the roadmap and to summarize / bring up / discuss any relevant organisation updates / issues in the preceding period.
I quite like this idea. Documents like a roadmap can easily go out of date if they're not actively maintained. Having a critical look at it once or twice a year will be helpful. Also +1 for adding some organizational items to it (I'm thinking CoC, FSA, etc. should have been on there).
The list of people on the steering committee also needs to be updated with this kind of frequency.
How about doing this around 1 January and 1 July every year?
I'm not sensing a lot of enthusiasm for the fixed-term/election idea,
I'm afraid the previous discussion on this thread has made it very unlikely that you would see any enthusiasm, even if, in another world, it was a good idea. That's the tragedy of mailing list discussions, as satirized here http://www.smbc-comics.com/?id=2939 and evident from the recent discussion on the Jupyter governance document. If anyone gets angry or dismissive about an idea, and that isn't addressed, that's a very effective way of inducing consent and shutting down the discussion. Cheers, Matthew
On Mon, Jan 16, 2017 at 12:39 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Mon, Jan 16, 2017 at 1:01 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sun, Jan 15, 2017 at 8:15 AM, Pauli Virtanen <pav@iki.fi> wrote:
Interesting discussion so far!
Sat, 14 Jan 2017 10:03:43 -0800, Matthew Brett kirjoitti: [clip]
What do you think about the idea of having regular state-of-scipy reviews to make sure we're conscious about keeping on track, assessing risks, improving process?
For the technical aspect, this sounds something like the Scipy roadmap (https://github.com/scipy/scipy/blob/master/doc/ROADMAP.rst.txt), and
the
discussion leading to it, in conferences and online in public.
Something like regular prompts for discussion of technical and organisation roadmap could be useful. At minimum, this could be simply a (bi-?)yearly post on the mailing list, to remind to update the roadmap and to summarize / bring up / discuss any relevant organisation updates / issues in the preceding period.
I quite like this idea. Documents like a roadmap can easily go out of date if they're not actively maintained. Having a critical look at it once or twice a year will be helpful. Also +1 for adding some organizational items to it (I'm thinking CoC, FSA, etc. should have been on there).
The list of people on the steering committee also needs to be updated with this kind of frequency.
How about doing this around 1 January and 1 July every year?
I'm not sensing a lot of enthusiasm for the fixed-term/election idea,
I'm afraid the previous discussion on this thread has made it very unlikely that you would see any enthusiasm, even if, in another world, it was a good idea. That's the tragedy of mailing list discussions, as satirized here
http://www.smbc-comics.com/?id=2939
and evident from the recent discussion on the Jupyter governance document. If anyone gets angry or dismissive about an idea, and that isn't addressed, that's a very effective way of inducing consent and shutting down the discussion.
Matthew, I think that's mis-characterizing this a bit. We had several governance discussion over the last years, and my impression was that the vast majority of those commenting where in favor of a more laid back approach instead of a fully specified constitution and associated discussion. (I think what's missing is a chair wo/man of the steering council and heads/lieutenants for each sup-package, and a specification of the rights of the release manager and maybe some more.) IMO, given the current contributors and the way contributors are recruited and integrated, I don't see much difference between unlimited time and fixed time with renewal. So, we can as well stick with what we know. Josef
Cheers,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org https://mail.scipy.org/mailman/listinfo/scipy-dev
On Tue, Jan 17, 2017 at 8:19 AM, <josef.pktd@gmail.com> wrote:
On Mon, Jan 16, 2017 at 12:39 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Mon, Jan 16, 2017 at 1:01 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sun, Jan 15, 2017 at 8:15 AM, Pauli Virtanen <pav@iki.fi> wrote:
Interesting discussion so far!
Sat, 14 Jan 2017 10:03:43 -0800, Matthew Brett kirjoitti: [clip]
What do you think about the idea of having regular state-of-scipy reviews to make sure we're conscious about keeping on track,
risks, improving process?
For the technical aspect, this sounds something like the Scipy roadmap (https://github.com/scipy/scipy/blob/master/doc/ROADMAP.rst.txt), and
assessing the
discussion leading to it, in conferences and online in public.
Something like regular prompts for discussion of technical and organisation roadmap could be useful. At minimum, this could be simply a (bi-?)yearly post on the mailing list, to remind to update the roadmap and to summarize / bring up / discuss any relevant organisation updates / issues in the preceding period.
I quite like this idea. Documents like a roadmap can easily go out of date if they're not actively maintained. Having a critical look at it once or twice a year will be helpful. Also +1 for adding some organizational items to it (I'm thinking CoC, FSA, etc. should have been on there).
The list of people on the steering committee also needs to be updated with this kind of frequency.
How about doing this around 1 January and 1 July every year?
I'm not sensing a lot of enthusiasm for the fixed-term/election idea,
I'm afraid the previous discussion on this thread has made it very unlikely that you would see any enthusiasm, even if, in another world, it was a good idea. That's the tragedy of mailing list discussions, as satirized here
http://www.smbc-comics.com/?id=2939
and evident from the recent discussion on the Jupyter governance document. If anyone gets angry or dismissive about an idea, and that isn't addressed, that's a very effective way of inducing consent and shutting down the discussion.
Matthew, I think that's mis-characterizing this a bit.
I think so too, but just in case: if anyone feels uncomfortable to contribute in this discussion on-list for whatever reason, then I'd much appreciate to hear his/her opinion offline (both on the governance topic and on what could have made contributing in public easier).
We had several governance discussion over the last years, and my impression was that the vast majority of those commenting where in favor of a more laid back approach instead of a fully specified constitution and associated discussion.
I think Pauli hit the nail on the head with this: "(i) the person can step down at any time, and acting in good faith, will also listen to serious calls to do so, (ii) regular elections can generate unnecessary work and politics -- looking at the past 10 years of scipy, there has been little of this, and I believe this is for the best, (iii) this is more of a role for fallback decision making and less for a director/CEO." (i) and (iii) would be good to add to the document itself I think.
(I think what's missing is a chair wo/man of the steering council
This could be helpful, just to be able to give that person the responsibility to ping everyone for bi-yearly updates, ensure the list of people stays up to date, contact people that have stopped being active about removal from the council, etc. and heads/lieutenants for each sup-package,
We used to have this, in a MAINTAINERS document. The added value wasn't high imho and it went out of date, so we removed it.
and a specification of the rights of the release manager
That's probably useful to add, will do so.
and maybe some more.)
Please add comments on the PR if more comes to mind. Ralf
IMO, given the current contributors and the way contributors are recruited and integrated, I don't see much difference between unlimited time and fixed time with renewal. So, we can as well stick with what we know.
Josef
On Wed, Jan 18, 2017 at 4:40 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Tue, Jan 17, 2017 at 8:19 AM, <josef.pktd@gmail.com> wrote:
On Mon, Jan 16, 2017 at 12:39 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Mon, Jan 16, 2017 at 1:01 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sun, Jan 15, 2017 at 8:15 AM, Pauli Virtanen <pav@iki.fi> wrote:
Interesting discussion so far!
Sat, 14 Jan 2017 10:03:43 -0800, Matthew Brett kirjoitti: [clip]
What do you think about the idea of having regular state-of-scipy reviews to make sure we're conscious about keeping on track,
assessing
risks, improving process?
For the technical aspect, this sounds something like the Scipy roadmap (https://github.com/scipy/scipy/blob/master/doc/ROADMAP.rst.txt), and the discussion leading to it, in conferences and online in public.
Something like regular prompts for discussion of technical and organisation roadmap could be useful. At minimum, this could be simply a (bi-?)yearly post on the mailing list, to remind to update the roadmap and to summarize / bring up / discuss any relevant organisation updates / issues in the preceding period.
I quite like this idea. Documents like a roadmap can easily go out of date if they're not actively maintained. Having a critical look at it once or twice a year will be helpful. Also +1 for adding some organizational items to it (I'm thinking CoC, FSA, etc. should have been on there).
The list of people on the steering committee also needs to be updated with this kind of frequency.
How about doing this around 1 January and 1 July every year?
I'm not sensing a lot of enthusiasm for the fixed-term/election idea,
I'm afraid the previous discussion on this thread has made it very unlikely that you would see any enthusiasm, even if, in another world, it was a good idea. That's the tragedy of mailing list discussions, as satirized here
http://www.smbc-comics.com/?id=2939
and evident from the recent discussion on the Jupyter governance document. If anyone gets angry or dismissive about an idea, and that isn't addressed, that's a very effective way of inducing consent and shutting down the discussion.
Matthew, I think that's mis-characterizing this a bit.
I think so too, but just in case: if anyone feels uncomfortable to contribute in this discussion on-list for whatever reason, then I'd much appreciate to hear his/her opinion offline (both on the governance topic and on what could have made contributing in public easier).
We had several governance discussion over the last years, and my impression was that the vast majority of those commenting where in favor of a more laid back approach instead of a fully specified constitution and associated discussion.
I think Pauli hit the nail on the head with this:
"(i) the person can step down at any time, and acting in good faith, will also listen to serious calls to do so, (ii) regular elections can generate unnecessary work and politics -- looking at the past 10 years of scipy, there has been little of this, and I believe this is for the best, (iii) this is more of a role for fallback decision making and less for a director/CEO."
(i) and (iii) would be good to add to the document itself I think.
(I think what's missing is a chair wo/man of the steering council
This could be helpful, just to be able to give that person the responsibility to ping everyone for bi-yearly updates, ensure the list of people stays up to date, contact people that have stopped being active about removal from the council, etc.
and heads/lieutenants for each sup-package,
We used to have this, in a MAINTAINERS document. The added value wasn't high imho and it went out of date, so we removed it.
I don't think it needs to be in the governance document. It illustrates the size difference in the organization compared to Debian for example. scipy has experts (developers familiar with code and topic) in some areas and generic maintainers (especially for topics without expert), but who is available fluctuates given the small numbers of maintainers relative to the size of scipy. .
and a specification of the rights of the release manager
That's probably useful to add, will do so.
and maybe some more.)
Please add comments on the PR if more comes to mind.
I think additional roles can be added in future, if the growth of scipy makes it large enough to require that those roles are formally defined. In general, I would prefer to have some impeachment clauses instead of just pointing at forking, but given that Pauli is the BDFL, I don't think it's necessary and we don't have to come up with a system for replacing the BDFL, chairman of the council and the council itself. Josef
Ralf
IMO, given the current contributors and the way contributors are recruited and integrated, I don't see much difference between unlimited time and fixed time with renewal. So, we can as well stick with what we know.
Josef
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org https://mail.scipy.org/mailman/listinfo/scipy-dev
participants (10)
-
CJ Carey -
Eric Larson -
Evgeni Burovski -
josef.pktd＠gmail.com -
Matthew Brett -
Nathaniel Smith -
Pauli Virtanen -
Ralf Gommers -
Stefan van der Walt -
Tiziano Zito