Closed dickwall closed 8 years ago
nafg
commented
8 years ago I wonder about the first bullet point. What percentage of scala users are on github? Is there any way to know? Voting is very different than discussion. Discussion is not mainly about consensus, it's mainly about clarifying the arguments and getting closer to the truth. On the other hand polling means you need to avoid anything that may bias the selection of data, and voting should exclude anyone.
Ichoran
commented
8 years ago Voting induces people to waste huge amounts of time on trying to get others to change their votes and on campaigning for votes. I vote against voting for this reason. Er, wait. Anyway: I like what this is trying to achieve, but I don't think voting is the way to do it.
So overall, I think it's unworkable, except possibly as a way to bleed off some of the nonproductive "-1" or "-1 but I will spend three paragraphs of general statements saying so" comments from SLIP threads.
SethTisue
commented
8 years ago Are there examples of other open source communities this has worked for?
bvenners
commented
8 years ago I'm not sure this is what is being proposed, but I would not recommend the future of the standard library be decided by majority vote, because not only would it be hard to manage the voting process, it would be hard to maintain cohesiveness of vision in the library.
The way I've seen other communities using voting is the community-at-large votes for a small group of people who then vote on proposals. The JCP has such a committee. The Jini community formed one, but it turned out I was the only person who ever put a proposal through it (ServiceUI, my first open source project, which is actually what stimulated me to write a Java test framework, SuiteRunner, my second open source project, which in 2008 I ported to Scala and called ScalaTest). I participated in forming the governance process for the Jini community, which was quite fun. I like design, and this was a different kind of design project than software design. And it sounds like we are starting to talk about process again here.
That said, I am not sure I we need an elected committee either. That seems quite heavyweight.
I don't know the details, but I also got the feeling that somehow the Python community had found a good approach that was possibly worthy of emulating. Guido van Rossum was the BDFL, but there was a lightweight process called PEP (Python Enhancement Proposal). That's actually where the name SIP came from:
http://osdir.com/ml/lang.scala.debate/2008-01/msg00151.html
Notice that my reply was to Martin's post in which he said that "I think modeling Scala's community process after Python's would be a good thing." I think we ought to look again at the Python community and see what they are doing now, and see if that wouldn't fit our community. I'll try and do that soon.
What we have now is a volunteer SLIP committee, and I trust everyone on there to listen. I trust Martin to guide things in a cohesive direction. My feeling is the SLIP committee should probably be making the final decisions on the standard library, and the community at large participate through debate and contributions of code.
bvenners
commented
8 years ago Oops, sorry, it was a long time ago so I'd forgotten, but it looks like I was the one who wrote "I think modeling Scala's community process after Python's would be a good thing," not Martin. So basically I guess I'm suggesting the same thing again 7 years later. I'll try and get an update on how things are going there to see if there's anything new we might want to emulate.
dickwall
commented
8 years ago Based on discussion in the gitter channel, I altered the keyword voting to survey, as it is a less loaded term. This discussion also doesn't state how the information might be used, only that we try and find a way to capture it in situations where it is too hard to summarize otherwise. Finally, this is a discussion of whether it should happen at all. Not sure if that clears anything up necessarily, but those were things I figured needed clarifying.
He-Pin
commented
8 years ago https://github.com/golang/proposal anything we could learn from golang?
ghost
commented
8 years ago I think in a community of thinking minds, vote should be avoid at all cost. I think is should only be used only as a last resort in case of emergency, basically as a last alternative to designate a single individual to take that decision even faster.
So what's the alternative? Debate until unanimity is reach (obviously with a guard against trolls), no opinions, just arguments. Why people want this thing to append? Why do they don't want it to? The goal is to understand everyone's point of view, the pains and gains induced by the decision, so that everyone's argument can be clearly exposed (perhaps preponderated by the size of affected people) to finally reach the ultimate truth about what is the best solution.
mdedetrich
commented
8 years ago The biggest problem with surveys, is that unless you go out of your way to do them properly (and there is a science to this), then you end up getting really skewed results. Some people can argue that its better than nothing, however in some cases it can be worse. In proposals (as we have seen), and surveys, you tend to get people with very strong biases/viewpoints generating most of the action, so you need to go out of the way to prevent this from happening.
This actually sought of happened in Haskell recently, they did a pretty fundamental change to their own prelude. It was voted with overwealming support, however the change altered one very fundamental aspect of code (long story short, length works on a lot of types which people legitimately claim it should not work on, which leads to a lot of "waaaaat" situations with code that compiles, when it arguably shouldn't. This matters a lot for a language that has such a huge emphasis on compile time safety).
It can be argued that if the survey was more rounded/less biased and more importantly, if people knew about all of the rammifications of the change (a lot of the proponents knew that the change would lead to this, but they didn't advertise it, mainly because they didn't see it as an issue), it might have been done differently. This is a link to the discussion that resulted from this change https://www.reddit.com/r/haskell/comments/3ojekh/excuse_me_i_think_this_is_my_stop_haskell_platform/
I definitely mirror that we should try and follow some process which has empirically worked out well. The python community seemed to have done this well, so has golang. Clojure is also really good in this regard.
Also if you are doing ballot style voting, you need to try and reach as many scala people as possible. So that can work, but you basically have to advertise on all of your channes (main typesafe site, epfl, reddit, slashdote, y combinator, twitter,facebook? etc etc)
The biggest problem always is, is that there are a huge number of people that use Scala, but for various reasons, are miles away from any sought of involvement. Those people do get affected by these changes.
bvenners
commented
8 years ago I checked out the Go link that @hepin1989 posted, https://github.com/golang/proposal. It describes a process in detail for changes, but doesn't say much about who behind the scenes is reviewing and making the decisions. My guess is that's inside Google somewhere, so it looks pretty different from Scala. I also glanced through:
https://blog.golang.org/open-source
That's very long, but interesting. Their philosophy is, "Do less. Enable more."
For Clojure I found a flow chart:
http://dev.clojure.org/display/community/JIRA+workflow
Looks like Rich Hickey is the BDFL (Benevolent Dictator For Life), and is quite involved in that process. Seems like he might become a bottleneck as things scale, but he does have helpers, called "Screeners," who appear to be appointed by Rich.
I also found a flow chart for Python community, and it seems to have fewer moving parts than the Clojure one:
http://docs.python-guide.org/en/latest/intro/community/
Guido van Rossum is and has always been the BDFL for Python. He also is ultimately the decider of library proposals too, as far as I can see, but he can (and I'm sure does, again to scale) delegate, as described in PEP1 and PEP2. PEP1 describes the process of changing the language itself, which is analogous to our SIP process:
https://www.python.org/dev/peps/pep-0001/#pep-review-resolution
PEP2 describes the process of adding (or removing, enhancing, etc.) something in the standard library, which is analogous to our SLIP process:
https://www.python.org/dev/peps/pep-0002/
The Library PEP process (defined by PEP2) talks about "integrators," which are people who I think are analogous to our SLIP committee. "This group of people shall be PythonLabs, led by Guido." So Guido is the ultimate decider on the standard library, but he has helpers.
One of the links I clicked on in the search results was one of my old interviews, which I'd forgotten about:
http://www.artima.com/intv/pycomm4.html
It gives some insight into how things worked in the Python world in the early days.
It appears both Python and Clojure are using a BDFL with helpers approach, and that's basically what we have now in the Scala world (with Martin Odersky as the BDFL). Our process documents are here:
http://docs.scala-lang.org/sips/
I feel the level of detail of Python's process documents is about right. It is substantial enough to guide people, but still lightweight. I might sound like a broken record turning very slowly, but I think modeling Scala's community process after Python's would be a good thing. I believe it did inspire our SIP process at the beginning, and we might want to look to it for inspiration again now for the SLIP process.
mdedetrich
commented
8 years ago @bvenners
Thats actually another good point. It seems that most "successful" (in regards to maintaining improvements to the language) have some sought of BDFL. Only exception is Go, but as you said, they probably have some internal process. I would be interest to see (in more detail) how RUST deals with this. They don't appear to have a BDFL, but it may be similar to what Go lang (just Mozilla instead of google).
I think the only language that is somewhat successful which is completely community orientated is Haskell.
bvenners
commented
8 years ago Yes, my observation is that benevolent dictatorship of design decisions is a good approach to governance for languages and libraries. You get consistence and coherence of vision that way. I'm the BDFL of ScalaTest and Scalactic, for example. I personally look at every single PR and make every final decision about those libraries. I certainly make mistakes and learn over time, and have tried to minimize the user pain of mistakes by being very conservative about putting anything in in the first place, and then working hard to migrate people carefully through deprecation cycles when it does happen.
I try and listen carefully to users and contributors to try and figure out the right path, but frankly have found it quite difficult to get feedback. Perhaps when people don't pay for something, they tend to not complain. But also it just takes their time to submit feedback, and they're busy. So it is collaborative, but at the end of the day one person decides.
In the case of the Scala language standard library, Martin Odersky is (and should be, in my opinion) the "BDFL," by which I mean the person who makes the final decisions. But it would never scale if he tried to do what I do in ScalaTest, which is inspect every PR. That's why I think we need the SLIP committee, to share the load. Dick Wall has been doing a lot of work to try and get the SLIP process rolling, since nothing had been happening for several years, and we want the standard library to improve over time just like we want the language to improve over time.
If I understand correctly, when Dick brought up voting and surveys, he was trying to address the problem I've definitely experienced myself that it is hard to figure out what users really want. I don't think voting or even surveys would be effective for that, but getting a good grasp of what people want is a real challenge. I read through the comments on the JSON SLIP and opinion seemed all over the map. What I think works best is for the decision makers to try and listen as best they can, then make the best decision they can.
dickwall
commented
8 years ago It seems clear from this discussion that no one wants an answer as simple as a survey for this, no one is a proponent, so we are closing this.
Possibly in time a voting circle based around module contributions to the core may be an option. Not ready for this yet.
At the time that this is considered, a new issue should be raised for that purpose.
I think this might be some kind of maturity milestone or something, but the recent discussions on https://github.com/scala/slip/pull/28 make it clear that we are at some point going to need a clear indication of majority will. While (currently) 287 comments are very encouraging, they are almost impossible to draw an overall picture of where the majority stand on this question. Despite having some concerns over the use of surveys, I can see no better way to judge the majority stake in something like this, so with the note that we won't be rushing into something half baked, I would like to start gathering ideas on a suitable mechanism for surveying on issues where the overall favor is unclear, or listen to proposals for fair alternatives, on this issue thread.
My own thoughts, concerns, such as they are (I allow myself to have them on the subject of process, but not on Scala right now :-) ).
The survey would be to provide clarification of the standing of a particular issue in the larger community, it has yet to be decided how that will affect the overall decisions, although one would assume it would be factored in.