In hindsight, it would’ve been a good idea to include some examples of features that didn’t get full blog posts during development but were still very well documented. Your work on precompilation and code caching are great ones, as are package extensions and hopefully soon JuliaSyntax support. Perhaps I’m dead wrong and most of the extended writing about those on GitHub, Discourse etc could’ve been avoided to deliver faster at an equal level of quality, but it feels like the enthusiasm and engagement they spawned were/are a net positive for overall development.
I absolutely agree. The intent behind focusing on the “missing middle” is exactly because this is not sustainable. On the other extreme, telling people that “absint: optimize more gfuncs on union-split” (made up PR title) is a big deal and leaving them to puzzle out what’s going on is also sub-optimal. Thus my question is: what can be learned from some of the aforementioned big features/changes which were well and frequently documented (outside of time-consuming blog posts/reports) to help other arguably important changes which were/are not?
Hey this is a good idea. Community involvement, and not slowing down core devs sound like very reasonable points. However, simply monitoring the repo could end up begin somewhat backward-looking, and I think there is a need for forward-looking statements for the broad community.
I think we could have a “future of julia” community post, that accepts PRs with small edits from relevant contributors (a lot less work than writing a full post). I’ll try to sketch something for my blog and will share back here.
I don’t know what would be the best way to do it… I guess anyone (for example, me) can start a repo trying to summarize some common sense forward-looking statements that are scattered all over the place (including TODO comments in source code, like one I just read going through how escape analysis is implemented in compiler.jl).
Eventually, if desired, the repo could be forked and included in the official docs, where it would continue to be an open-source document, only that it could be owned by the offcial mantainers of Julia.
I think one version of your take here is just that many PRs to julialang/julia could stand to be more descriptive. To me, many PRs at least look like they were discussed/reviewed offline (which they probably were, which seems totally fine), and unfortunately there’s a lack of detail in the github record. I’m not sure exactly how one can add that detail in without adding overhead to the process though. (But also, I think @tim.holy’s PRs often provide a lot of information and detail, so I don’t think these comments are that applicable to his).
I’ve really appreciated what KitWare does with their various projects, e.g. ParaView. They use GitLab’s Milestones tracker that gives a rough idea of which issues are “accepted” for being fixed, as well as provides a rough idea for when a user might see them. Each milestone then has a kanban interface that can provide additional context for users.
It’s not perfect, nor do users (or at least me), hold them to it - but it is nice to know when they’ve “picked up” my issue so that I can assist (e.g. additional context & MWE, testing) however I can. A few times that’s been through getting them funding (one way or another) to get an issue on a milestone board (i.e. “approved” for work), or prioritized within a board.
(Just joking) Please enable the GitHub sponsor feature so that I can ask for roadmaps as a sponsor
Although promising the deliverability at a specific date can be very hard for open-source projects, I do think there can be roadmaps on:
what developers care about in the next few releases, and
if we have a scratch solution to solve them.
Maybe we shouldn’t write the roadmap directly but instead, generate it by filtering out the accepted juleps. That could at least give users a good estimation of what could be seen in the near future. If we agree on this, then we can try to standardize the julep process (a better triage workflow for long-term goals?).
One thing I have often wished for is a technical roadmap, for lack of a better phrase. I’d like to know what changes are desired, to know where contributions might be accepted, even if no developer currently intends to work on those changes. I feel like this is important for cultivating non-maintainer contributors who can offer specific amounts of time but not a long-term commitment.
However, publishing such a thing might risk people treating it as a timeline, demanding the new features and hounding maintainers. I wonder if that is the reason why these sorts of “technical roadmaps” don’t appear very often in larger projects. The alternative ends up being an assortment of comments at the bottom of issues or on Slack where a maintainer eventually says “PRs welcome”, but sometimes it is difficult to tell whether that is an invitation for a PR author to contribute a desired feature, or an expression of skepticism.
I do feel like there are a few things where “we can’t have Z until X and Y are implemented”, where sometimes one of X or Y are a matter of toil vs expertise, where they don’t require significant guidance from a maintainer (I think the great docstring push was a good example, as well as upgrades to deal with breaking changes in Julia from <v1). I wonder if those could be communicated in some way without causing the problems described here.
One thing that’s worth noting is that most contributions that are helpful aren’t the type of thing that would be on a roadmap. The best contributions for casual contributors IMO are things like performance, docs, or one-off bugs. These types of improvements tend to be relatively isolated from other stuff and don’t require much in the way of design or understanding interactions between different parts of code.
which keep track of progress on different areas, including “experimental” packages.
This looks like a community effort, but I don’t really know as apparently the Rust Project/Foundation likes to centralize things a lot.
Something like this could be possible for static compilation perhaps. Given that a number of core devs said that this has become a priority now, in my case, I’ll just wait out for the next “State of Julia” talk by Jeff, or maybe ask about this on a separate thread.
People like to really misunderstand large language models… Acting like they are knowledge oracles or teachers or search engines or whatever… all of which is extraordinarily inappropriate.
If there were one role where they actually seem appropriate, it’s to hand them a bunch of text written by experts and ask them to rewrite it in a more accessible summary form. Particularly if the person consuming the output is someone who understands the important stuff in the input, it should be possible to get some not-wrong output way quicker than tasking the expert to write it from scratch.
Is there a place where Juleps are being standardized and I could start working on a small one? I’ve found that discourse is friendly but not the most productive place for standardizing ideas and proposals and slack is far too impermanent. I don’t like throwing noise in the Julia issues because real issues are more important than my developing proposals.
I also generally find their writing style painful to read. GPT is the biggest idiot you know, confidently and incorrectly going on about topics it doesn’t understand with the fluffiest language. It is grates me.
Anyway, I have no problem vomiting text onto a screen.
This text would need cleanup, but I don’t trust LLMs enough to do that cleaning for me without review and editing, especially on tone. If I have to do all that, why not cut out the LLM-middleman?
A lot of people find it difficult to get started, or find it difficult to take detailed information and figure out what’s most appropriate for the audience, or find it difficult to do any number of tasks that are relevant. Those same people may find it relatively easy to take the output of an LLM tasked with rewriting and approve or disapprove it. They may even find it easy to modify the resulting text for tone or minor content or factual problems. If you don’t find that easy, then fine. It’s just a suggestion. But if all the tasks that an LLM could be given, rewriting text is one of the most appropriate. As compared to for example the recent news case where a lawyer had asked it to write a legal brief from scratch complete with made up citations etc.
I think the main thing with a Julep is you should note that it’s a proposal of work you’re planning to do yourself, or at least, your team. That’s what Tim is trying to highlight here. The reason there is no standardized way to do Juleps, nor will there be any attempt to, is because it’s essentially putting the work in to tell other people what you want them to do, which you can simply consider wasted time. If they are formalized, then I think people will get the impression that writing a Julep will get it done, but that of course is a wrong expectation. Expect to do it in order to get feedback and what you will eventually have to implement.
The only reason why I would write a Julep is of course because I do interface with the teams, and I’d be summarizing the goals of the teams since some of the individuals are much more adept at coding than at quickly summarizing ideas to a large audience for feedback. But to be clear, the Juleps we’re writing are things we’re planning to do and are asking people for feedback and who wants to join in on the activity.
I ask because it would have been very useful to have a little more structure going to into things like my somewhat (very) messy attempt to implement a low-level memory type previously. I don’t pretend to be an expert above the core devs, but I imagine some sincere feedback and conversation is helpful.
Also, i think converging on a structured format for proposals might be a useful way of engaging other parts of Julia’s ecosystem where there is a real intent to do work. I tend to get burnt out on the back and forth on discourse and I usually try not to tag people on github unless I know in advance they are interested.
As an update to my mentioning of KitWare’s timeline, check out this issue regarding desired changes to their color legend properties editor. The discussion started on their Discourse, and a GitLab issue created. It’s been assigned to the Fall 2023 release, to be funded by Sandia.
Again, I have ~10% confidence that it will actually be done by the fall, but it does let me know that this is planned work and that I should periodically check to see if any assistance (e.g. user testing, feedback) is needed…
A couple of points in defense of those who ask for roadmaps/timelines (I can’t remember the last time I did):
Typically when you ask about a certain feature/bug fix it’s because it is hindering progress. Understanding timelines/roadmaps helps you to know if you should wait for the “pros” to handle it, do a workaround to fit your situation, or try a different package
For someone who isn’t a dev on a certain package it is hard to get a vision of what is happening. Open source software is constantly in flux. I think many questions about roadmaps and timelines are people trying to orient and align themselves to how to integrate packages into their own workflow
