# Identifying barriers to new contributions to Julia and its ecosystem

**URL:** <https://discourse.julialang.org/t/identifying-barriers-to-new-contributions-to-julia-and-its-ecosystem/124342>\
**Category:** Community\
**Tags:** github, contributing\
**Created:** [January 1, 2025, 7:29pm UTC](https://discourse.julialang.org/t/identifying-barriers-to-new-contributions-to-julia-and-its-ecosystem/124342 "2025-01-01T19:29:21Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![Lilith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lilith/32/27492_2.png) [@Lilith](https://discourse.julialang.org/u/Lilith)\
**Post date:** [January 1, 2025, 7:29pm UTC](https://discourse.julialang.org/t/identifying-barriers-to-new-contributions-to-julia-and-its-ecosystem/124342/1 "2025-01-01T19:29:21Z")

</div>

Hey folks,

I’ve been investigating pathways to contribution to the Julia ecosystem. Specifically, I’m looking for barriers to new contributors joining open source Julia projects and how to alleviate them. If you have ideas, questions, or personal experience to share, I’d be glad to hear it!

I also want to share a teaser of some of the data I’m looking at. Here’s a plot focusing specifically on how responsive folks are on the JuliaLang/julia repo. Looking at pull requests to JuliaLang/julia opened in 2022 and 2023, 78% were merged within a year, 18% were responded to within a year but not merged within a year, and 4% were neither responded to nor merged within a year. Of the first two categories, here’s a distribution of how long it took to respond:

 ![response_time_vs_merge](https://global.discourse-cdn.com/julialang/original/3X/a/3/a35bc80a922654460b9c431a17714385b1deafbb.png)

There will certainly be more to come; I am sharing this to open the conversation and invite others to chime in.

---

<div class="post-metadata">

**Author:** ![langestefan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/langestefan/32/207923_2.png) [@langestefan](https://discourse.julialang.org/u/langestefan)\
**Post date:** [January 1, 2025, 7:53pm UTC](https://discourse.julialang.org/t/identifying-barriers-to-new-contributions-to-julia-and-its-ecosystem/124342/2 "2025-01-01T19:53:52Z")

</div>

I recently contributed some things to JuMP.jl and ModelingToolkit.jl. My experiences were very good.

For SciML in general the only feedback I have is that because the ecosystem is so large it can be difficult to figure out where the (little) thing you want to change is located at. GitHub’s new search functionality has really helped in this respect.

---

<div class="post-metadata">

**Author:** ![g-gundam](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/g-gundam/32/47593_2.png) [@g-gundam](https://discourse.julialang.org/u/g-gundam)\
**Post date:** [January 1, 2025, 8:11pm UTC](https://discourse.julialang.org/t/identifying-barriers-to-new-contributions-to-julia-and-its-ecosystem/124342/3 "2025-01-01T20:11:17Z")

</div>

## People don’t realize how easy it can be to help.

One little thing that I do occasionally is send in a pull request for documentation fixes. It’s actually a really easy thing to do, because Documenter.jl provides a link at the top of every page to get the process started.

![image](https://global.discourse-cdn.com/julialang/original/3X/c/f/cf0f16051b9eeee454fc619c3937cc2f8c93df04.png)

Clicking on that pencil icon will take you to the github page for that document. On github, you’ll see another pencil icon.

![image](https://global.discourse-cdn.com/julialang/original/3X/1/5/159690d5767e2feadad3f83c5a544d6b576d8d43.png)

Clicking on that pencil icon will fork the repo and create a branch. From there, you can edit the markdown document directly from github, and when you’re done, you’re prompted to create a pull request. The process is streamlined.

## Fixing a typo here and there is so easy.

More people should do it when they notice the opportunity. Also, from the original developer’s perspective, a pull request for documentation fixes is about as low stress as you can get if it’s a small one. You can usually tell at a glance that it should obviously be merged in, and it’s a good feeling for everyone involved.

---

<div class="post-metadata">

**Author:** ![mitiemannn](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mitiemannn/32/206115_2.png) [@mitiemannn](https://discourse.julialang.org/u/mitiemannn)\
**Post date:** [January 1, 2025, 8:39pm UTC](https://discourse.julialang.org/t/identifying-barriers-to-new-contributions-to-julia-and-its-ecosystem/124342/4 "2025-01-01T20:39:07Z")

</div>

Multiple things needed to happen before I’ve even decided to consider contributing to Julia:

- I’ve needed to overcome my imposter syndrome. I’d be curious how many people share this experience. To me, the bigger and “more impressive looking” a codebase/community is, the bigger the feeling of “what could I possibly contribute?”.
- I agree with @g-gundam that contributing to documentation is a great way to get started. I for one didn’t know about how streamlined this process is (thank you!) and when I’ve started, I also didn’t realize how much of a help it would be just helping keeping the documentation up to date or providing the perspective from a newcomer.
- This might be particular subjective - again, I’d love to hear y’all perspectives: the more open issues and PRs there are in a repo, the bigger my fear of “am I duplicating other people’s effort”, sometimes combined with “(and their effort is probably better)”. I’m often afraid/expecting that I might have missed an issue/a PR that is already doing what I intend to do and in that case, I don’t want to pile onto the workload of the maintainers.
- For PRs in particular: I’m often uncertain how much effort a given feature/bug fix/anything might require and I don’t know whether I might find the time/energy to keep working on it. On the other hand: I don’t want to leave tasks unfinished, so I end up not even starting a task.  
In summary: many of the burdens that I experience(d) are mental barriers that might not even be related to technical difficulty of the problem. On the other hand: the positive and supportive vibe of the Julia community in particular has been very helpful to lower these mental barriers for me \<3

Also, I highly applaud your efforts, @Lilith , in this direction \<3

---

<div class="post-metadata">

**Author:** ![matthias314](https://avatars.discourse-cdn.com/v4/letter/m/a88e4f/32.png) [@matthias314](https://discourse.julialang.org/u/matthias314)\
**Post date:** [January 2, 2025, 12:13am UTC](https://discourse.julialang.org/t/identifying-barriers-to-new-contributions-to-julia-and-its-ecosystem/124342/5 "2025-01-02T00:13:59Z")

</div>

I would like to share my own experiences with contributing to Julia itself (which I hope is within the scope of the OP). While I think the Julia community very welcoming, the difficult part comes once a PR is submitted. I have several PRs where for quite some time already I have been waiting for responses, see below. I’m sure everyone is busy, so I don’t want to blame anyone. Still, not getting feedback does not really encourage me to contribute more. In one case my PR (#54060) was a response to a call for help by one of the maintainers, so that I found the silence particularly puzzling. I think it would be great if one cold get faster responses, maybe including a contact person to ping and directions how to proceed with a PR (drop feature X, add Y).

EDIT: I often did get a (positive) initial response. The discussion died off later, when I had questions or when I thought the PR would be ready to merge.

> <https://github.com/JuliaLang/julia/pull/52304>
>
> The purpose of this PR is to finally add \`instancemethods\` to master. This funct…ion was created by @algunion in #50898 and #51068 in response to a \[question\](https://discourse.julialang.org/t/how-to-determine-the-methods-for-a-callable-object-without-instantiating-it/102618) of mine on Discourse. @algunion seems to be busy at the moment and \[said\](https://github.com/JuliaLang/julia/pull/51068#issuecomment-1771808720) that I could complete the PR.
> 
> Recall that the idea of \`instancemethods(T::Type)\` is to return all methods for instances of \`T\` without the need to instantiate any object. I believe I have addressed all comments made in #51068. Some remarks about the current version:
> 
> \* The code for \`methods\` contains the line
> 
> https://github.com/JuliaLang/julia/blob/9ea29d9b8f41509ea2609ce012cea69dfc4285e8/base/reflection.jl#L1187
> 
> which is currently not in \`instancemethods\`. Does it need to be added?
> 
> \* ~~The following gives an error at present:~~
> \`\`\`
> julia\> length(instancemethods(Function)) # OK
> 24726
> 
> julia\> length(instancemethods(Any)) # EDIT: OUTDATED
> ERROR: UndefRefError: access to undefined reference
> Stacktrace:
> \[1\] getproperty
> @ ./Base.jl:49 \[inlined\]
> \[2\] instancemethods(t::Type, tmatch::Any, mod::Nothing)
> @ Base ./reflection.jl:1275
> \[3\] instancemethods
> @ Base ./reflection.jl:1283 \[inlined\]
> \[4\] instancemethods(t::Type)
> @ Base ./reflection.jl:1283
> \[5\] top-level scope
> @ REPL\[9\]:1
> \`\`\`
> EDIT: Besides \`Function\` (which is already dealt with), also \`Any\` and \`Core.Builtin\` have the property that \`Base.typename(T)\` has no field \`mt\`. This is fixed now.
> 
> EDIT 2: \`instancemethods(Core.Builtin)\` gives an empty method list although \[builtin functions\](https://docs.julialang.org/en/v1.11-dev/devdocs/functions/#Builtins) are instances of this type. Is this a problem?
> 
> \* If/when the PR gets accepted, we need to add something to NEWS.md. Where would it go there? To "New language features", to "New library features" or elsewhere?

> <https://github.com/JuliaLang/julia/pull/53824>
>
> \## The problem
> 
> I think the signatures generated for docstrings create problem…s when type parameters are involved. This can be seen when searching docstrings based on signatures. My understanding of the intended behavior is that only docstrings matching the given signature should be displayed or, if none exists, all docstrings for the given function. This works well without type parameters, but not with them. I reported this already in #52669, but I didn’t get any response. The present PR intends to fix this issue. The underlying problem is somewhat subtle, so I try to explain it in detail.
> 
> EDIT: The builds fail because a change in \`doc/src/stdlib/SparseArrays.md\` is needed, see below.
> 
> \## Examples
> \`\`\`
> help?\> filter(iszero)
> \`\`\`
> displays the two docstrings
> \`\`\`
> filter(f, a)
> filter(f)
> \`\`\`
> although the first one doesn't match the signature.
> \`\`\`
> help?\> NamedTuple(\[:a =\> 1, :b =\> 2\])
> \`\`\`
> displays
> \`\`\`
> NamedTuple{names}(args::Tuple)
> NamedTuple{names,T}(args::Tuple)
> NamedTuple{names}(nt::NamedTuple)
> NamedTuple(itr)
> \`\`\`
> although only the last one matches.
> 
> \## What is going wrong?
> 
> Here are the signatures used by the help system for the examples above:
> \`\`\`
> julia\> using Base.Docs: META, @var, signature
> 
> julia\> function docsigs(f, M::Module)
> @eval keys(getfield($M, META)\[@var $f\].docs)
> end;
> 
> julia\> docsigs(:filter, Base)
> KeySet for a IdDict{Any, Any} with 4 entries. Keys:
> Tuple{Any, Base.SkipMissing{\<:AbstractArray}}
> Tuple{Any, AbstractDict}
> Union{Tuple{N}, Tuple{T}, Tuple{Any, Array{T, N}}} where {T, N}
> Tuple{Any}
> 
> julia\> docsigs(:NamedTuple, Base.BaseDocs)
> KeySet for a IdDict{Any, Any} with 4 entries. Keys:
> Union{Tuple{Tuple}, Tuple{T}, Tuple{names}} where {names, T}
> Union{Tuple{Tuple}, Tuple{names}} where names
> Tuple{Any}
> Union{Tuple{NamedTuple}, Tuple{names}} where names
> \`\`\`
> The third entry for \`filter\` comes from
> https://github.com/JuliaLang/julia/blob/d68a04ee9cc9f5479cf729b1bda17d950d4951ba/base/array.jl#L2875
> as can be seen via
> \`\`\`
> julia\> signature(:( filter(f, a::Array{T, N}) where {T, N} ))
> :((Union{Tuple{Any, Array{T, N}}, Tuple{N}, Tuple{T}} where N \<: Any) where T \<: Any)
> \`\`\`
> The type parameters \`T\` and \`N\` have been added as signatures, which leads to wrong search results.
> 
> The first entry for \`NamedTuple\` comes from
> https://github.com/JuliaLang/julia/blob/d68a04ee9cc9f5479cf729b1bda17d950d4951ba/base/docs/basedocs.jl#L3306
> Here the same happens with the parameters \`names\` and \`T\`, even in the absence of a \`where\` clause:
> \`\`\`
> julia\> signature(:( NamedTuple{names,T}(args::Tuple) ))
> :((Union{Tuple{Tuple}, Tuple{T}, Tuple{names}} where T \<: Any) where names \<: Any)
> \`\`\`
> 
> \## The problematic code
> 
> The signatures attached to docstrings are generated by the function \`Base.Docs.signature!\`. PR #21036 added among other things the following statements:
> https://github.com/JuliaLang/julia/blob/f65b8aba9abb9f0bd0f2da5fba8cc3eb1475cef1/base/docs/Docs.jl#L91-L96
> The \`for\` loop adds type parameters from \`where\` clauses as additional signatures, which was the problem for \`filter\`. In the absence of \`where\` clauses, the \`if\` statement does the same with \`:curly\` expressions. We have seen this for \`NamedTuple\`.
> 
> \## Proposed solution
> 
> The PR deletes these two loops. As far as I can tell, searching docstrings by signatures then works as expected. However, docstrings attached to constructors like
> \`\`\`
> NamedTuple{names}(args::Tuple)
> NamedTuple{names,T}(args::Tuple)
> \`\`\`
> cannot be distinguished anymore because the signatures of the arguments are the same. Attaching a docstring to the second call replaces the first one. At present they can be distinguished, and this may have been the motivation for #21036.
> 
> That having different docstrings for constructors differing only by a type parameter could have been the original motivation is also indicated by two tests in \`test/docs.jl\`. One checks that the signatures have the (now problematic) form, and the other one checks that different docstrings can be attached to constructors like the \`NamedTuple\` example above. I’ve modified the former test and marked the other one as \`@test\_broken\`. \`NamedTuple\` is the only case where I have seen this problem. (I've compiled Julia and loaded all standard libs.) I've merged the corresponding docstrings into one. I have also changed two lines in the documentation.
> 
> Also, docstrings attached to constructor calls with parameters must now use a \`where\` clause if the parameter is used for the arguments. For example,
> \`\`\`
> "doc" A{T}(x::T)
> \`\`\`
> is currently allowed, but would have to be written
> \`\`\`
> "doc" A{T}(x::T) where T
> \`\`\`
> For this reason, one needs the following additional change to build the documentation. The file is from a different git repository, see \[here\](https://github.com/JuliaSparse/SparseArrays.jl/blob/main/docs/src/index.md).
> \`\`\`
> $ diff doc/src/stdlib/SparseArrays.md.orig doc/src/stdlib/SparseArrays.md
> 240c240
> \< permute!{Tv, Ti, Tp \<: Integer, Tq \<: Integer}(::SparseMatrixCSC{Tv,Ti}, ::SparseMatrixCSC{Tv,Ti}, ::AbstractArray{Tp,1}, ::AbstractArray{Tq,1})
> \---
> \> permute!{Tv, Ti, Tp, Tq}(::SparseMatrixCSC{Tv,Ti}, ::SparseMatrixCSC{Tv,Ti}, ::AbstractArray{Tp,1}, ::AbstractArray{Tq,1}) where {Tv, Ti, Tp \<: Integer, Tq \<: Integer}
> \`\`\`
> With this change the documentation builds without problems.
> 
> \## Changing less?
> 
> (ADDED) One could avoid the changes just mentioned if one kept part of the code that I delete, namely the lines that treat \`:curly\` expressions like \`where\` clauses. This is problematic, however, because on the level of expressions free parameters cannot be distinguished from constant parameters. Consider the following example:
> \`\`\`
> struct A{T} end
> "doc Int" A{Int}(x::Int) = A{Int}()
> "doc T" A{T}(x) where T = A{T}()
> \`\`\`
> The signature for the first docstring would be converted to \`Tuple{Int} where Int\`, which is the same as \`Tuple{Any}\`. Hence \`help?\> A{Int}(1.0)\` would display both docstrings although the first one doesn't match. (This is also the current behavior.)
> 
> \## Conclusion
> 
> I think that the current situation is not desirable and should be changed. Whether the proposed PR is the right way to go is up for debate. That docstrings can be attached to function calls (instead of method definitions) is not documented, I believe. In this sense one could say that the change made by this PR would be non-breaking. In any case, let me know what you think.

> <https://github.com/JuliaLang/julia/pull/54060>
>
> This PR makes the following symbols from \`Base.Broadcast\` public:
> 
> \- Symbols a…ppearing in the documentation, with docstring
> \`\`\`
> AbstractArrayStyle
> ArrayStyle
> Broadcasted
> DefaultArrayStyle
> Style
> combine\_axes
> combine\_styles
> flatten
> instantiate
> result\_style
> \`\`\`
> 
> \- Symbols appearing in the documentation, \*\*without\*\* docstring
> \`\`\`
> Unknown
> \`\`\`
> 
> \- Symbols \*\*not\*\* appearing in the documentation, with docstring
> \`\`\`
> materialize
> \`\`\`
> I think it makes sense to make it public given that \`Broadcasted\` is also public.
> 
> \- Symbols \*\*not\*\* appearing in the documentation, \*\*without\*\* docstring
> \`\`\`
> DefaultMatrixStyle
> DefaultVectorStyle
> \`\`\`
> I think it makes sense to have them available as shortcuts. Maybe one should even mention them in the documentation instead of using \`DefaultArrayStyle{1}\`, for example.
> 
> EDIT: Making \`DefaultVectorStyle\` and \`DefaultMatrixStyle\` public leads to failing doctests because they now appear in the Julia output instead of \`DefaultArrayStyle{1}\` and \`DefaultArrayStyle{2}\`. However, they are never used in broadcast.jl. If one doesn't want to have them public, why are they defined at all? Let me know if you want to have them public. Then I adjust the documentation.
> 
> \- The following functions have been left out although they have docstrings:
> \`\`\`
> broadcast\_preserving\_zero\_d
> broadcast\_shape
> make\_makeargs
> newindex
> \_broadcast\_getindex
> \`\`\`
> 
> \- The following symbol (with docstring) is currently exported \*\*without\*\* appearing in the documentation:
> \`\`\`
> BroadcastFunction
> \`\`\`

> <https://github.com/JuliaLang/julia/pull/55669>
>
> I think that the current implementation of \`x in itr\` is identical to \`any(==(x)…, itr)\`, see below. An added bonus of calling \`any\` is that a more efficient implementation of \`any\` for a custom type will most likely give an efficient implementation of \`in\` for that type at the same time.
> 
> https://github.com/JuliaLang/julia/blob/3a2a4d8dd74d4d5780a78e059f767578bb376618/base/reduce.jl#L1220-L1238

> <https://github.com/JuliaLang/julia/pull/55671>
>
> This PR makes three changes to the way \`any\` and \`all\` calls are transformed int…o 3-argument \`\_any\` and \`\_all\` calls for \`AbstractArray\`:
> 
> \- \`any(a)\` is transformed to \`any(identity, a)\` instead of calling 2-argument \`\_any\`, and analogously for \`all\`. I think this has the following advantage: If somebody wants to implement \`any\` for a custom \`AbstractArray\` type, then it is now enough to define the 2-argument \`any\`. Currently also the 1-argument version has to be defined explicitly.
> 
> \- The restriction that the predicate \`f\` for the 2-argument versions of \`any\` and \`all\` be of type \`Function\` has been removed. None of the other methods for the 2-argument versions of \`any\` and \`all\` impose this, and I see no reason to have it here.
> 
> \- I've deleted the explicit definitions of the 2-argument versions of \`\_any\` and \`\_all\`. They are covered by the following line
> https://github.com/JuliaLang/julia/blob/39f2ad1e941fd092b906d60e8d23c004e8ee5b7e/base/reducedim.jl#L1007
> in the \`for\` loop a few lines later. (I believe that it doesn't matter anyway. As far as I can tell, the 2-argument \`\_any\` and \`\_all\` were only used for the 1-argument \`any\` and \`all\` and nowhere else.)

(For #55671 I now realize that the deadlock might be caused by a misunderstanding. I did get an answer, but not of the yes/no form I was expecting.)

> <https://github.com/JuliaLang/julia/pull/55673>
>
> The new methods allow for vectorization and are therefore much faster: With nigh…tly, I get
> \`\`\`
> julia\> t = ntuple(Returns(true), 32); @b any($t)
> 2.440 ns
> 
> julia\> t = ntuple(\>(4), 32); @b any($t)
> 5.014 ns
> 
> julia\> t = ntuple(Returns(false), 32); @b any($t)
> 22.961 ns
> \`\`\`
> With this PR,
> \`\`\`
> julia\> t = ntuple(Returns(false), 32); @b any($t)
> 2.638 ns
> \`\`\`
> As for other \`Tuple\` methods, this is only done up to length 32. Beyond that, the generic method is called. At present, the cut-off is 3 elements.
> 
> I find this quite useful. What you think?

> <https://github.com/JuliaLang/julia/pull/55711>
>
> Keyword arguments are mentioned several times in the discussion of the recent \`F…ix{N}\` PR #54653. However, support for them was dropped in the end. I don't know if that was to keep \`Fix{N}\` simple or for more fundamental reasons. I would like to propose \`FixKw\` as a way to do for keyword arguments what \`Fix{N}\` does for positional arguments. I think it should exist for the sake of completeness. It is also helpful because \`map\`, \`reduce\` and the like don't allow to pass keyword arguments to the function one uses.
> 
> I've chosen the name \`FixKw\` to resemble \`Fix\` although the "fixed" keyword arguments can still be overridden. I'm open to other names.
> 
> Please let me know what you think. If you like it, I can add tests and update \`NEWS.md\`.

---

<div class="post-metadata">

**Author:** ![adienes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/adienes/32/37459_2.png) [@adienes](https://discourse.julialang.org/u/adienes)\
**Post date:** [January 2, 2025, 2:10am UTC](https://discourse.julialang.org/t/identifying-barriers-to-new-contributions-to-julia-and-its-ecosystem/124342/6 "2025-01-02T02:10:44Z")

</div>

this might sound counterintuitive, but I think one possible area of improvement for the contribution experience would be a greater willingness / predisposition for maintainers to close some PRs / issues with a more prompt “no / not planned” rather than leaving them open, unresponded — or worse, with active discussion sucking up screen space / mindshare when it’s clear to many that no actionable conclusion will be reached

---

<div class="post-metadata">

**Author:** ![woclass](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/woclass/32/212699_2.png) [@woclass](https://discourse.julialang.org/u/woclass)\
**Post date:** [January 2, 2025, 3:07am UTC](https://discourse.julialang.org/t/identifying-barriers-to-new-contributions-to-julia-and-its-ecosystem/124342/7 "2025-01-02T03:07:29Z")

</div>

> [@Lilith](#):
>
> some of the data I’m looking at.

Another data source: History Pull Request Time Cost data + real-time data

[https://ossinsight.io/analyze/JuliaLang/julia#pull-requests](https://ossinsight.io/analyze/JuliaLang/julia#pull-requests)

---

<div class="post-metadata">

**Author:** ![woclass](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/woclass/32/212699_2.png) [@woclass](https://discourse.julialang.org/u/woclass)\
**Post date:** [January 2, 2025, 4:21am UTC](https://discourse.julialang.org/t/identifying-barriers-to-new-contributions-to-julia-and-its-ecosystem/124342/8 "2025-01-02T04:21:08Z")

</div>

> [@mitiemannn](#):
>
> For PRs in particular: I’m often uncertain how much effort a given feature/bug fix/anything might require and I don’t know whether I might find the time/energy to keep working on it. On the other hand: I don’t want to leave tasks unfinished, so I end up not even starting a task.

> how much effort a given feature/bug fix/anything might require

My experience is that the process of fixing or just determining the root cause of a problem can easily jump into a rabbit hole.  
Maybe you spent an afternoon determining that the issue could not be reproduced on the platform you were using, which is common as a Windows user.  
So it’s actually hard to estimate the effort required to fix one issue.

> I don’t know whether I might find the time/energy to keep working on it

My way of thinking about it: **choose an issue you really care about** , not the ones that seem easy to fix.  
That way, even if you don’t make much progress on this attempt, when you have free time again, you can continue your attempts without being bothered by wasted time.

> I don’t want to leave tasks unfinished

I think it’s normal to open a draft PR (or mark it as a WIP) even if you don’t end up finishing it.  
My old draft pr: (2 year ago) [[win] Fix source build without pre-built deps by inkydragon · Pull Request #45712 · JuliaLang/julia](https://github.com/JuliaLang/julia/pull/45712)

I am still concerned about the issues involved in pr#45712.  
If I had more free time, I would move forward with it.  
And of course I would be happy to see others move forward based on this PR and eventually replace it.

* * *

Another newer example: (2 weeks ago) [build: remove openlibm by inkydragon · Pull Request #56875 · JuliaLang/julia](https://github.com/JuliaLang/julia/pull/56875)  
This PR is a POC that already passes the CI check for the windows platform, but still needs more cleanup before it can be merged.

It may still take months to merge it.  
But that’s not a big problem, since its predecessor JuliaLang/julia#42299 opened in 2021.  
(By the way #42299 was opened by Viral B. Shah)

---

<div class="post-metadata">

**Author:** ![matthias314](https://avatars.discourse-cdn.com/v4/letter/m/a88e4f/32.png) [@matthias314](https://discourse.julialang.org/u/matthias314)\
**Post date:** [January 3, 2025, 1:57pm UTC](https://discourse.julialang.org/t/identifying-barriers-to-new-contributions-to-julia-and-its-ecosystem/124342/9 "2025-01-03T13:57:49Z")

</div>

In the examples I mentioned above, I often got what I considered an encouraging, positive first response. The discussion stalled later, for example when I asked in which way some modification should be done, or even when I thought the PR would be ready to go. It’s unclear to me why it stalled. Sometimes I asked whether/how to move forward with the PR, and I didn’t get any reply.

---

<div class="post-metadata">

**Author:** ![langestefan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/langestefan/32/207923_2.png) [@langestefan](https://discourse.julialang.org/u/langestefan)\
**Post date:** [January 3, 2025, 2:01pm UTC](https://discourse.julialang.org/t/identifying-barriers-to-new-contributions-to-julia-and-its-ecosystem/124342/10 "2025-01-03T14:01:07Z")

</div>

> [@mitiemannn](#):
>
> I’ve needed to overcome my imposter syndrome. I’d be curious how many people share this experience. To me, the bigger and “more impressive looking” a codebase/community is, the bigger the feeling of “what could I possibly contribute?”

Definitely true. @ChrisRackauckas is genuinely a nice guy so if you’re contributing to SciML packages that already helps a lot!

---

<div class="post-metadata">

**Author:** ![raman\_kumar](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/raman_kumar/32/26782_2.png) [@raman\_kumar](https://discourse.julialang.org/u/raman_kumar)\
**Post date:** [January 4, 2025, 7:43am UTC](https://discourse.julialang.org/t/identifying-barriers-to-new-contributions-to-julia-and-its-ecosystem/124342/11 "2025-01-04T07:43:14Z")

</div>

[Asahi Linux](https://asahilinux.org/) developer streams their work on this [Youtube channel](https://www.youtube.com/@AsahiLina). We can have a similar channel about Julia development where Julia developers can upload their videos. Such type of open development can help new developers to learn faster. 🤔

---

<div class="post-metadata">

**Author:** ![Eben60](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/eben60/32/13475_2.png) [@Eben60](https://discourse.julialang.org/u/Eben60)\
**Post date:** [January 4, 2025, 4:27pm UTC](https://discourse.julialang.org/t/identifying-barriers-to-new-contributions-to-julia-and-its-ecosystem/124342/12 "2025-01-04T16:27:34Z")

</div>

> [@Lilith](#):
>
> 78% were merged within a year, 18% were responded to within a year but not merged within a year, and 4% were neither responded to nor merged

Not that bad actually!

Would be interesting to have similar statistics for the most popular packages.

---

<div class="post-metadata">

**Author:** ![g-gundam](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/g-gundam/32/47593_2.png) [@g-gundam](https://discourse.julialang.org/u/g-gundam)\
**Post date:** [January 5, 2025, 2:54am UTC](https://discourse.julialang.org/t/identifying-barriers-to-new-contributions-to-julia-and-its-ecosystem/124342/13 "2025-01-05T02:54:28Z")

</div>

We don’t have any VTubers, but we did have a doggo.

 ![doggo_dot_jl](https://global.discourse-cdn.com/julialang/original/3X/6/9/6960ab73da3762f00fbb76fe291462a210b96b37.png)

> **[doggo dot jl](https://www.youtube.com/@doggodotjl)**
>
> 2024-01-01 Notice
> I am currently on hiatus.
> \---
> henlo fren!
> 
> Welcome to doggo.jl, where I explore the vast Julia wilderness and turn my discoveries into wholesome Julia tutorials!
> 
> The Julia Programming Language is the highest-level programming...

---

<div class="post-metadata">

**Author:** ![raman\_kumar](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/raman_kumar/32/26782_2.png) [@raman\_kumar](https://discourse.julialang.org/u/raman_kumar)\
**Post date:** [January 5, 2025, 5:29am UTC](https://discourse.julialang.org/t/identifying-barriers-to-new-contributions-to-julia-and-its-ecosystem/124342/14 "2025-01-05T05:29:45Z")

</div>

No, I am asking for a Youtube channel where development videos of Julia and its packages can be streamed. That Doggo channel is for learning Julia and not its development. Please see this Asahi Youtube channel to understand difference.

> [@raman\_kumar](#):
>
> [Asahi Linux](https://asahilinux.org/) developer streams their work on this [Youtube channel](https://www.youtube.com/@AsahiLina).

---

<div class="post-metadata">

**Author:** ![Fliks](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fliks/32/2494_2.png) [@Fliks](https://discourse.julialang.org/u/Fliks)\
**Post date:** [January 5, 2025, 7:25am UTC](https://discourse.julialang.org/t/identifying-barriers-to-new-contributions-to-julia-and-its-ecosystem/124342/15 "2025-01-05T07:25:42Z")

</div>

During the lockdowns there have been some people streaming their development work. There is a not that active anymore streaming channel on slack.