Report a bug in Julia or a standard library function
Enhancement (automatically labels with Enhancement)
Suggest a new method/functionality for an existing feature
Feature Request (linking to discourse)
Please suggest new features on Discourse
(the second layer is the descriptive subtext).
That way, we can direct explicit (long form) feature requests to discourse, while keeping small “new method” things to be tracked directly. Hopefully without an overhead as large as Rust or Go have (though I very much think having someone explicitly manage these organizational parts would be helpful, I can see that there’s a lot of pushback against this kind of active management).
The redirect to Discourse is good but should include a recommended title/tag so that the request has the same specificity and visibility to the repo maintainers as an issue. Conversations like this help, but it’s important to summarize these norms so that people can quickly understand how they can play their part.
I’m not sure that can be done - I’m not even sure if we can link to creating a topic in a specific category. It’s something to look into.
We’re certainly at a disadvantage with this approach of having feature requests on discourse compared to Rust, because Rust is using a dedicated Discourse for the langauge design specific discussions, as far as I’m aware. We’re mixing A LOT of different topics on our discourse.
That’s cool! However, the linked meta post suggests “trying it out right here on meta”, so I clicked on the link and just got redirected to their homepage, due to not having a discourse account on meta… No error or other user facing message that this is required in sight (not to mention losing the prefilled information).
So it seems like this only works for the subset of people who already have a discourse account & are actively logged in.
While a good thought, the space in the template that ends up below the button is at a premium:
I’m not sure we can fit all the requirements we’d like to use on Discourse in there, and have it be easy to follow for non-native english speakers as well. We ought to configure this in such a way to automate as much as possible of the process, to keep things easier to do & manage.
What happened to this discussion? Might be worth continuing IMHO.
And one point I want to add: some core contributors, are not nearly as active here on discourse than they are on GitHub (and the other way around for regular users). This can lead to division and miscommunication. In practice, core contributors eventually get much more say on whether a feature will happen or not, so people might spend lots of energy discussing a thing here on discourse (let’s assume reaching some form of agreement) and a resulting feature request issue on discourse gets closed pretty quickly. (I must admit that for this reason I’ve in the past “asked” about some features on GitHub first, to not waste my time).
To expand on this a little more, the trend of where Julia is conceptually heading in a certain area (say, multithreading) - which is important to judge if a feature request is going in the right direction and has a chance of happening - is, to my knowledge, not written down anywhere. At best, it’s encoded in people, specifically often a small set of core contributors. I guess that’s, to some extent, pretty normal for open source projects. But that also makes contributing ideas harder and especially so if you discuss them with a different set of people (on a different platform).
Is it normal for projects around the same size and popularity as Julia, though? I anecdotally know of languages both larger and smaller which have a more structured RFC process. The answer might be yes, but IMO it would be good to know so we have a benchmark to work off.
AFAIK, the Juleps repo has been abandoned for some time and any queries about reviving it have been mostly met with apathy. Unless there is a strong will to bring it back for real this time, I’d only consider it a historical curiosity for the purposes of this discussion.
The discussions panel of the main repo is reasonably active, and seems like the most correct place to discuss potential features which aren’t well enough defined to add to the issue tracker.
My overall impression is that the development process in Julia is quite a bit more chaotic than I’ve seen in languages of a comparable caliber, and it would be good to see that change. I don’t have any strong or useful ideas about how, just the bare observation.
Did github discussions always looked like that? I never noticed.
But I agree that looks like a great place (especially with the voting mechanism, that users could use to signal things important to them without the need to write comments).
We would just need to make this information known and easily findable, so people would actually use it.
Hi @mnemnion, I understand what you feel but let me gently disagree with your hope for change, I’d say your impression is because you’re used to democratic project which is the standard in open source for collaboration. I believe it’s a bad standard and prefer sociocratic organisations, specially in a constantly changing environment like we have in software dev. The main difference is the way decisions are taken: consensus in democracies, consent in sociocracies.
I believe the development process of julia is more oriented toward consent and thus belongs to a non formal sociocratic model. It’s a far more resilient and proactive model than what you can find in other projects and it’s one of the many reasons why julia is so good.
If you’re interested in the subject this article is a good start: https://www.sociocracyforall.org/organizational-circle-structure-in-sociocracy/
Concerning feature requests imho a good policy is to use github for the “how” to keep contributors focused on the job and use “whatever is good for discussion” for the “why” and “what”, discourse is good for that.
I’m not yet a contributor to Julia, which will unfortunately remain the case as long as I’m unable to build it. That leaves me uncomfortable with critiquing a process I’m not a part of in any detail, I don’t expect I’d do a good job and am sure it wouldn’t be welcome.
But I can say that your interesting observation about democratic vs. sociocratic models (I’d never heard of the latter) has little bearing on my impression. I’m not sure how you read through my one sentence on the subject to come to the conclusion about it which you did, but that conclusion is mistaken.
Is the Julia process officially sociocratic? Or is that a term you enjoy using to model it?
Being officially sociocratic is a kind of formalism which clearly mislead the process itself, it would ruin opportunities. Formalism is opposed to incrementalism (https://publik.tuwien.ac.at/files/publik_267101.pdf).
Keeping formalism minimal optimize complex problems solving. That’s why it can seem chaotic like you said, there’s not a single way to do, “it depends on the people” in some way, and democracy vs sociocracy is just a picture to characterize the differences.
For someone with a background like mine, the process is cristal clear and optimal, the match with sociocracy is concrete.
For ex. when I see a subject like that: Are there any plans for Julia to adopt an effects system?
It’s a classic heuristic of pre-feature request, you test if the idea can get traction and start to build a “circle” of interested people around a problem. When those people collaborate often to solve alike problems, a “mission circle” emerge. Julia Data is a typical example of mission circle, it has even its own domain name: https://juliadata.org
Another characteristic of sociocracy (or incremental problem solving) and why decisions are taken by consent, is because consensus produce soft decisions that rarelly fully satisfy someone.
Base rules embrace the fact we cannot satisfy everyone so they consist of being transparent about your intention, listening to everyone IN the circle, and if there’s no formal opposition, do your stuff to test your idea.
Once the decision is taken everybody should support it, because the aim is to genuinely experiment the idea and avoid to sabotage its testing by making resistance.
Juleps cited earlier is a typical example of this kind of experiment. It didn’t work, but it was worth trying and now we know it’s not the way to do for us, we learnt, we move on.
This is also probably why @ToucheSir (sorry to cite you directly, correct me if I’m wrong) muted the recent thread about ScopedValue. As the decision has been taken, even if we disagree, we should support his idea. If we don’t, we can obfuscate the reasons of a failure (or a success) and ruin a learning opportunity. Now it’s too late to talk about the name, it’s time to use it and collect enough feedback to maybe improve it later with new informations. Once again this is typical of how sociocracy works, but let’s not be reductive by naming something, it’s just better to keep it as a simple picture and not to make it a formal process.
Now that being said, the actual issue is about: where should Julia feature requests go ?
From a sociocratic perspective this is not an issue, this is a feature
In democracy every voice counts, in sociocracy relevant voices count. To be relevant means you’re durably involved in a circle of people and collaborate with them to achieve a common goal. You cannot collaborate with random people, you have to know them and share the same goal, otherwise this is just cooperation.
Having a fixed answer on where should Julia features requests go, means you decide for all circles how they should be organized to permit random people to contribute.
Why do you want that ? You accept their contribution and then who’s responsible to maintain it ? Do we have enough core contributors and are they willing to spend their precious time on thousands of random1234user you’ll never see again to check and maintain their maybe relevant contribution…? How do you know if process X is better than process Y ? in which situation ? A ? B ? or C which has not happened yet and is not previsible ? …
No judgement, I understand some can feel uncomfortable with incertainty and look at following clear directives, it’s how it’s done on most projects to communicate and reassure people; the idea that everyone can contribute is beautifull too and I sincerely wish everybody can… but sorry, this is not realistic, it’s a huge amount of additional work for core developers, we know the ideal team size is between 4 and 7 persons (due to information propagation…), that experienced teams define their own methods toward a problem and that enforcing one globally reduce motivation and bride problem solving capacity…
So I believe it’s good to keep this question open, let people find their way on how to contribute without impersonating relationships, and let teams being organized the way they want to discover what’s working for them. Diversity is a gift.
There’s too much to say, I’ve sincerely tried to make it short
@mnemnion sorry you have an issue to compile julia on mac, I would help you with pleasure if I could.
Although it’s certainly novel to see an off-hand comment of mine analyzed this way, I’m afraid that wasn’t the intent. For the record, I just had no strong opinion on the whole naming discussion beyond not wanting it to spiral out of control like some past discourse topics have.
Back to the whole philosophical discussion (which IMO should be its own thread), I don’t know if we need to employ this kind of abstract classification to understand the very concrete challenges around managing additions/changes to Julia? To elaborate, here are some points I’ve learned about the current state of things:
Julia development is mostly conducted by a small core team
In turn, the majority of this group works at a limited number of companies/institutions which contribute financially and staff-wise to Julia development
Many languages people compare Julia to have access to significantly larger corporate (including non-profit) or academic resources, whether that be funding or skilled (often full time) developers
In the absence of such resources, the natural approach has been to turn to the broader Julia community for help
Though there have been improvements in giving this broader community increased involvement in core development, the general perception is that more is required to enable substantial improvements to the core language, stdlibs and supporting functionality. Hence topics like the one which started this thread.
While there’s certainly no hurt in trying to look at the question of “where should Julia feature requests go?” from a philosophical or systems of governance perspective, I suspect most people following this thread are here for concrete ideas about how to improve the status quo.
I wonder if there would be less need for requests if the Julia core developers would explain their vision for Julia and use Juleps for important upcoming features.
Being officially sociocratic is a kind of formalism which clearly mislead the process itself, it would ruin opportunities. Formalism is opposed to incrementalism (
