# Why open-source timelines/roadmaps don't work **URL:** \ **Category:** Internals & Design\ **Created:** [May 28, 2023, 4:32pm UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518 "2023-05-28T16:32:10Z")\ **Posts on this page:** 20\ **Page:** 2

**Author:** ![ToucheSir](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/touchesir/32/14411_2.png) [@ToucheSir](https://discourse.julialang.org/u/ToucheSir)\ **Post date:** [May 30, 2023, 3:49pm UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518/21 "2023-05-30T15:49:46Z")

> [@tim.holy](#): > > Have you found a way to blog about your own contributions without it taking a lot of time? If so, what’s your secret? Unfortunately no, but I wish 🙂 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. > [@jlapeyre](#): > > Asking volunteers whose time is stretched thin why they can’t just please make a little effort and write a report for me, seems presumptuous. If you want something like this, do some work to set up a system to make it easier and then maybe they’ll use it (probably not). 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? ---

**Author:** ![martin.d.maas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/martin.d.maas/32/50964_2.png) [@martin.d.maas](https://discourse.julialang.org/u/martin.d.maas)\ **Post date:** [May 30, 2023, 5:49pm UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518/22 "2023-05-30T17:49:46Z")

> [@tim.holy](#): > > These are great roles for community participation! One of you could start a “this week in Julia development” newsletter, where you monitor Julia’s GitHub and then write things up in an manner that can be understood by a wider audience. That way it doesn’t slow down developers and word gets out about the cool happenings in Julia development. 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. ---

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\ **Post date:** [May 30, 2023, 5:51pm UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518/23 "2023-05-30T17:51:24Z")

> [@martin.d.maas](#): > > I think we could have a “future of julia” community post That sounds an awful lot like an open-source timeline/roadmap 😉 ---

**Author:** ![martin.d.maas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/martin.d.maas/32/50964_2.png) [@martin.d.maas](https://discourse.julialang.org/u/martin.d.maas)\ **Post date:** [May 30, 2023, 6:10pm UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518/24 "2023-05-30T18:10:03Z")

Yeah, that would be exactly the point. 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. ---

**Author:** ![jar1](https://avatars.discourse-cdn.com/v4/letter/j/c0e974/32.png) [@jar1](https://discourse.julialang.org/u/jar1)\ **Post date:** [May 30, 2023, 6:13pm UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518/25 "2023-05-30T18:13:58Z")

Jeff has been speaking about the state and future of Julia in these videos [![](https://global.discourse-cdn.com/julialang/original/3X/7/9/796a9a32b26a769ea50d0c51c3f247796a147a66.jpeg "The State of Julia (In 2022) with Jeff Bezanson | JuliaCon 2022") ](https://www.youtube.com/watch?v=N4h46_TCmGc) ---

**Author:** ![ericphanson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ericphanson/32/215186_2.png) [@ericphanson](https://discourse.julialang.org/u/ericphanson)\ **Post date:** [May 30, 2023, 6:17pm UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518/26 "2023-05-30T18:17:17Z")

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). ---

**Author:** ![Krastanov](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/krastanov/32/6817_2.png) [@Krastanov](https://discourse.julialang.org/u/Krastanov)\ **Post date:** [May 30, 2023, 9:42pm UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518/27 "2023-05-30T21:42:52Z")

**Author:** ![GregVernon](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gregvernon/32/5611_2.png) [@GregVernon](https://discourse.julialang.org/u/GregVernon)\ **Post date:** [May 30, 2023, 10:03pm UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518/28 "2023-05-30T22:03:12Z")

> [@ToucheSir](#): > > But surely other languages must have this problem too? Most definitely, but it is also worth exploring what approaches they have taken to fill this “missing middle” of status updates. I’ve really appreciated what KitWare does with their various projects, e.g. ParaView. They use GitLab’s [`Milestones`](https://gitlab.kitware.com/paraview/paraview/-/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. ![image](https://global.discourse-cdn.com/julialang/original/3X/a/9/a92845789f8e940ca035e652b7a2369601519be5.png) 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. ---

**Author:** ![JohnnyChen94](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnnychen94/32/29979_2.png) [@JohnnyChen94](https://discourse.julialang.org/u/JohnnyChen94)\ **Post date:** [May 31, 2023, 10:18am UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518/29 "2023-05-31T10:18:51Z")

(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](https://github.com/JuliaLang/julia/issues?q=is%3Aopen+is%3Aissue+label%3Ajulep). 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?). ---

**Author:** ![iamed2](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/iamed2/32/215082_2.png) [@iamed2](https://discourse.julialang.org/u/iamed2)\ **Post date:** [May 31, 2023, 1:47pm UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518/30 "2023-05-31T13:47:30Z")

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 \ **Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\ **Post date:** [May 31, 2023, 2:11pm UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518/31 "2023-05-31T14:11:09Z") 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. ---

**Author:** ![martin.d.maas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/martin.d.maas/32/50964_2.png) [@martin.d.maas](https://discourse.julialang.org/u/martin.d.maas)\ **Post date:** [May 31, 2023, 6:12pm UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518/32 "2023-05-31T18:12:35Z")

Rust also has a lot of pages like this one: > **[Index](https://www.arewelearningyet.com/)** > > The comprehensive guide to the state of machine learning in Rust. This site catalogs ML frameworks, data structures, data cleaning and analysis, and other tools and libraries that are essential to machine learning ecosystems. 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. ---

**Author:** ![dlakelan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dlakelan/32/8491_2.png) [@dlakelan](https://discourse.julialang.org/u/dlakelan)\ **Post date:** [June 4, 2023, 3:43pm UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518/33 "2023-06-04T15:43:59Z")

> [@tim.holy](#): > > Have you found a way to blog about your own contributions without it taking a lot of time? If so, what’s your secret? 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. ---

**Author:** ![Zach\_Christensen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zach_christensen/32/7220_2.png) [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)\ **Post date:** [June 5, 2023, 6:03pm UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518/34 "2023-06-05T18:03:16Z")

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. ---

**Author:** ![Elrod](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/elrod/32/22461_2.png) [@Elrod](https://discourse.julialang.org/u/Elrod)\ **Post date:** [June 5, 2023, 6:11pm UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518/35 "2023-06-05T18:11:35Z")

I don’t trust large language models at all. 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? ---

**Author:** ![dlakelan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dlakelan/32/8491_2.png) [@dlakelan](https://discourse.julialang.org/u/dlakelan)\ **Post date:** [June 6, 2023, 1:37pm UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518/36 "2023-06-06T13:37:07Z")

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. ---

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\ **Post date:** [June 6, 2023, 11:32pm UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518/37 "2023-06-06T23:32:29Z")

> [@Zach\_Christensen](#): > > Is there a place where Juleps are being standardized and I could start working on a small one? 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. ---

**Author:** ![Zach\_Christensen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zach_christensen/32/7220_2.png) [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)\ **Post date:** [June 6, 2023, 11:45pm UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518/38 "2023-06-06T23:45:50Z")

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. ---

**Author:** ![GregVernon](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gregvernon/32/5611_2.png) [@GregVernon](https://discourse.julialang.org/u/GregVernon)\ **Post date:** [June 8, 2023, 4:06am UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518/39 "2023-06-08T04:06:22Z")

> [@GregVernon](#): > > 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. 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](https://discourse.paraview.org/t/promote-color-legend-properties-editor/12017), and a [GitLab issue created](https://gitlab.kitware.com/paraview/paraview/-/issues/22165). It’s been assigned to the Fall 2023 release, to be funded by Sandia. ![image](https://global.discourse-cdn.com/julialang/original/3X/f/9/f91a3260582b329033f09774511817acdd1577ce.png) 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… ---

**Author:** ![bisraelsen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bisraelsen/32/3974_2.png) [@bisraelsen](https://discourse.julialang.org/u/bisraelsen)\ **Post date:** [June 20, 2023, 7:48pm UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518/40 "2023-06-20T19:48:56Z")

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 [Previous page](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518.md?page=1) [Next page](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518.md?page=3)