I’ve been loathe to engage on some of the recent threads on this forum, but I care greatly about this community so I felt it necessary to articulate my position in one coherent piece with all relevant background. It has gotten a bit longer than I intended, but I’m hoping it will resonate with community at large and maybe at the end suggest a way to improve the situation.
An open source project is not the collection of lines of code that make up its repository. At its core, an open source project is the sum of commitment and sacrifice of time, energy, money and sanity by the contributors to such project. By such contributions, I don’t mean contributions in code, or contributions to (in our case) JuliaLang/julia, but any such contributions to the community whether in code, in documentation or in community engagement (evangelism, organizing meetups, etc.). In a successful open source project, those efforts are aligned and working towards a common, larger whole. In chaos, no such whole forms.
As such, and as always in the organization of community efforts, the question is how such alignment can be achieved, given the diverse background, technical opinions, languages and cultural backgrounds of those involved is a difficult one and does not have an easy solution. In some communities, e.g. Python or Linux, a single individual is vested with this power and responsibility; I believe Rust has a core team that shares this responsibility, and yet others (particularly Linux distributions) solve this by equal vote of a certain set of eligible voters. However, whatever the governance model of an open source project is, it is upheld by the assent of the contributors to the project and the trust that those vested with this power, by the contributors, will continue to steer the project in the same manner that has led to prior success. If, in the course of events, such assent should fail, the legal underpinnings (i.e. the license) of most open source projects (and projects with the MIT license in particular) allows those contributors to take the code and re-create the open source project with a different mode of governance that then once again enjoys the support of the project’s contributors. Such, events are fairly rare and can surely cause the death of a project, but there are also plenty of examples where everything worked out fine in the end (e.g. Jenkins, MariaDB, LibreOffice and probaly others if I knew my history better).
In the julia community, we do not, so far, have a formal governance model. Decisions tend to get made by consensus of those who care about a subject. This consensus need not be uniform, but generally we do not make changes while there is major discord amongst the people interested in a particular area. On occasion, when technical disagreements arise and can not get resolved by consensus of those participating in the discussion, they will get resolved by requesting other well respected members of the community to consider the issues. As a consequence, hopefully a consensus is reached amongst this larger group of people. I do not consider this an abandonment of the principle of decision by consensus, but a consequence of the effect that a controversial change causes more people to become interested in a discussion. The triage process, by which issues can be flagged for discussion on a weekly call, is to my mind, a more formalized version of precisely this process.
One last point I want to make about this is that, when considering the arguments, different view points are not weighted equally. Those that have a long history of well-considered and successful technical contributions to the julia community will be given more weight than those who do not. Those that present verifiable, repeatable, hard data cogent to the topic of discussion will be given more weight than those who do not. Those who can present their suggestions succinctly and actionably will have more influence than those who can’t. Those who care passionately about a topic will be given more weight than those who do not. Those who are willing to do the work for something are weighed more heavily than those who are not. Perhaps this is unfortunate, but it is a very useful heuristic by which to asses the arguments. In general the number of arguments greatly exceeds the time that would be advisable to spend on resolving them. As a concrete example, if I come up with some cool new widget to add to the language, I will consider an “I don’t know, feels funny”, much more seriously from, say Jeff, than from somebody who just learned Julia for the very first time.
However, I hope this also makes it more clear how somebody can make their opinion on a given subject count. One way is through a long history of high-quality technical contribution, but another is by presenting clear evidence for your position, arguing it well and succinctly and being willing to do whatever the work is that your position would require doing. This may seem unfair at times (“Why was I asked to back up my position, when core contributor X could just state their opinion?”), but I think it is a necessary part of how decision making operates. The time availability of the core contributors (for code review, for implementing the tricky bits of infrastructure, etc.) is a significant limiting factor in making sure that development does not grind to a halt.
In this, I was very careful to specify technical contributions to this community however. The courtesy of highly weighing someone’s technical opinion is an extension of the trust of the contributors to the project and as such is earned over time. It is not bestowed, or inherently present by prior qualifications, whether academic, from research, or by development experience open source or otherwise. Those qualifications should help in arguing the point and thus make it more likely to convince other people of the technical merits of one’s ideas, but do not, by themselves, grant trust bestowed upon those who have been
productively contributed to the community for a long time. When I contribute to open source projects of which I am not a core contributor, I will generally spend (and am asked to spend) significantly more time on commit messages, cleanup, collecting data and arguing for a change than I generally would in this community. This is not a reflection of my contributions to those communities being of lower quality or that I am less qualified to contribute to those projects, but simply that I have not yet earned the trust of the members of such communities in my technical judgement. I do get frustrated by this at times, but in the end they will have to live with the consequences of my work, so I feel that asking me to justify my position is their prerogative.
With that background on my view of the community and its decision making process as a whole, I’d like to turn my attention to the community forums, such as Discourse and Slack. The reason many of us participate in this community is to share our work and our passion with the world at large, to alleviate the pain felt when having to use bad technology and (in this community in particular) to provide tools for the advancement of human knowledge. As such, places like this forum and the Slack chat exist, in order that those who use our work may ask questions about it, may provide feedback, may make technical suggestions and engage in technical discussions, and (perhaps most useful) may have an organized way to engage with the core contributors of the julia community. However, as such it is a representation of the contributors’ wish to share their work with the world, not an independent end in itself. There are certain structures and rules imposed upon this forum, that, by consensus of the contributors, are the contributors’ best idea of how to achieve the above mentioned goals. In our community, this includes the Community Standards, and the Community Stewards’ system.
The reason these structures exists is to be welcoming. To make it clear that people should have general expectations of civil discourse. To be clear as to the expectations when joining this community and to set a clear sign that the people working on this project care about the users and want to engage here and elsewhere in order to help make effective use of our work.
I do not think this goal is best achieved by allowing this or any other such forum to become a free-for-all. This forum is not a democracy, nor does it provide unabridged free speech. It is a tool to allow for the large user base to engage with the contributors of the language, and it has imposed upon it the structure chosen by these contributors. And while we generally wish to allow all pertinent discussion, if there is a consensus amongst the contributors that certain discussion is counter-productive to the declared goal of the platform, then that is the decision that is taken. The difference between this forum and others that may exist is it is operated as an extension of the project and is the place where you may discuss with the contributors of the project. By the consensus of the contributors, this is the place where the contributors wish to engage with the community at large, and this is the place which is governed by such rules as deemed proper by consensus of the contributors and moderated by those trusted by the contributors to take proper and reasonable action. Those who do not like this structure are free to create their own forum with different rules, but just as they need not accept the structure of this forum, the contributors need not engage in any such new forum, except by their individual choice.
Which lastly brings me to the standards of discourse on this forum. There has been some concern over forum post perceived as rude or otherwise unproductive. I would encourage everyone to adopt a presumption of non-maliciousness on behalf of the authors of such posts. This community brings together people from many different cultural backgrounds and speakers of many different languages. Communication across such boundaries is not straightforward, and connotations and meaning in written language can be radically different depending on that background.
If a post does come up that can be interpreted in an unfortunate manner, the best course of action is to point that out in private. Assuming, again, non-maliciousness on the part of the author, they were probably unaware of the connotations of their post. A private message brings such connotations to their attention and avoids escalation. A similar function can be achieved by flagging a post for moderator attention (or messaging a moderator a more precise concern) such that the moderators may talk to the individual on your behalf. The moderators are here to uphold the values of the community. This is not an easy task, but as with post authors, please make sure to assume the best intentions on behalf of the moderators. It may be useful to have more clear guidelines on which moderation tools are to be deployed in what situations, but I would hope that standards of courteous discourse and assumption of good motivations would obviate their use in all but extreme situations. Lastly, and as a matter of last resort, there are the community stewards to which a complaint may be escalated (e.g. for disagreements with the moderators).
That said however, there has been unfortunate trend of attempting to air such grievances in public. This generally achieves little. Rather than being made aware of an unfortunate comment, people now feel attacked (by being accused of, contrary to their intention, having caused great offense) and feel the need to defend themselves. This is not productive and only escalates the situation.
We have all made statements that in the fullness of time we have come to understand were inartfully phrased. I know I have. Let’s all take a deep breath here, take a step back and consider if there isn’t a better way to avoid these problems in the future.
from me.