Hello everyone, I am starting this thread to ask you what is your opinion regarding the payment of a salary to a freelancer to maintain and fix issues in Plots.jl? We have various volunteers in the community helping with issues in the Plots.jl repository but the project is too central to be maintained as a side project. As far as I know, most contributors have other priorities in their agendas. The pace at which issues are addressed is simply too slow.
I’d be happy to pay $5 a month to someone for example to have a number of issues fixed per week. Assuming 500 people join an initiative like this we could sum up $2500 for example. I guess we have much more than 500 users? I am also assuming that many users in the community have a good financial status and could easily pay $5 or more per month? Would you be interested? What is your take on this?
I wonder if the Julia community has mechanisms or platforms to connect freelancers to projects? I know about GSoC and other initiatives, but I think they don’t solve the problem in the long-term.
I fully agree with you here @PetrKryslUCSD. Also, my secret wish is a recipe system specifically designed for GR or Makie. I would be 100% happy with that.
Currently, we have tons of backends that are simply too different to fit on the same umbrella, and the authors of the backends don’t have time to figure out the Plots.jl glue code.
In other words, the original idea of supporting all kinds of backends doesn’t scale when it comes to maintenance. Specially when only a few people have the necessary knowledge to fix issues.
The crux here is twofold. People who are good at using the backend libraries don’t need the Plots-interface, while people who are using Plot usually do so, because they don’t want to learn the backend API.
I think one way forward would be to have better documentation of how the backend code works, because once you got that, writing and maintaining a backend is not that hard (at least easier than learning a new plotting API).
In theory, yes. In practice, no. The recipe system in Makie does not work with custom types yet. There are various open issues in the various repositories.
I don’t know. The issue is more about someone fully committed to maintain and evolve the system with more features, not so much about learning how to contribute as a sporadic contributor. I am sure we all can learn internals of Plots.jl given the necessary time. The problem is that we are all doing our own thing, and Plots.jl is not a priority.
If we had GR + recipes maintained by GR devs, this system would naturally evolve. Issues would be quickly fixed and wouldn’t pile up in the issue tracker.
I am happy to donate for someone to maintain Plots, even though I am more of a gnuplot.jl user myself. That being said, the hiring should be done at the organization level (say julia pro) where the salary is “crowdsourced”.
Yea one issue here is that plotting “tastes” in general are much more heterogeneous than other areas of the ecosystem. My preferred backend changes depending on which types of plots I am making at the time! The issues in Plots.jl seem more about the interaction between Plots.jl and a particular backend, so there would need to be some consensus on which would receive the paid work and which would not.
As much as some people would probably hate this type of funding model, I agree with @affans that perhaps any large-scale efforts are likely better centrally planned. That is, the community does a fundraising drive and the money goes to the Julia Project, who then decides where to add hired help – perhaps with some input from the community.
…Now that I look at it, the NumFOCUS donation page does have a box asking if there is a particular package you would like your funds to support. So it seems like this might be the easiest way to get things done.
I don’t know. I think it is more about people struggling to contribute code when there is so much to keep track of, even when the contributor has interest in a specific backend.
We know that the attempt to unify all backends in a single API has a price: the lack of specific features only available in specific backends. GR has tons of exciting features that are not available through Plots.jl for example.
That is a very good idea. If we could at least direct funds to specific projects like Plots.jl things could get better.
As someone who fixes a few issues now and then I can tell you that Plots.jl is not centralized and structured enough to be more aggressive about shutting invalid/non-reproducable issues and out the scope FRs. Real critical issues get covered pretty fast. And I do not mean this in a bad way. I feel that every issue deserves to be open, but most of the issues are backend installation issues and FRs. The ratio of the issues are as follows (my feeling):
50% Backend installation issue (+precompilation, GR package build, etc.)
15% actual bugs
15% unexpected behavior (not critical)
20% FRs.
If there was a payed incentive to close issues, we could just aggressively close issues of category 1,4 immediately and that would seem like there are so many issues being closed at a fast rate.
In reality, there is progress, but it mostly focuses on 2,3, and sometimes 4. A lot of issues with precompilation and installation just pile up slowly. I instead think that people should stop treating issues as a place to ask how to successfully install an operational backend.
There was GSoC, but Plots requires people who are fairly knowledgable about backend specifics and plotting in general as a concept. It is hard to find bite sized pieces as I feel that plotting, in general, is not a modular/separable problem. Even running tests is not trivial as it is hard to easily quantify what is a bug and what is not.
Lastly, some people do not understand why Plots exists, why choose Plots over other libraries. Plots is first and foremost a convenience layer for fast plotting/testing/prototyping, and it also happens good enough for complex plots too. Plotting complex interactive 3d with different colorscales with broken axes should not be even done with Plots. It is simply not the right tool for that. The API is made simple for convenience. FRs get rejected/ignored because they ask for very specific use-cases that are difficult to implement with a simple API.
The donations could really help out, I do not object that. I feel that there needs to be a community manager/mod to help clear out invalid issues and help with documentation more than a developer. Right now, I feel that Plots could use fresh documentation and basic FAQ. Cleaner docs would really go a long way.
Yeah, there are good developers already, I think we are missing out on communication and docs.
Sorry, but that is not true. It is good to be positive, but that is not the reality we face. I have plenty of experience with multiple critical issues that are not fixed yet. Also, the concept of critical is subjective. What is critical to me may not be critical to you and vice-versa.
I don’t think that is the goal, that is to close issues just for the sake of closing them. I started this thread to point out that there is no person currently guiding the direction of Plots.jl forward. Someone with a vision of where it should go, what are the priorities and a plan with a clear agenda to fix things and add more features.
Exactly. The reality is that most contributors are sporadic contributors. They have the knowledge but they don’t have the time. The whole point is that Plots.jl deserves someone fully committed to the project to add features proactively as opposed to in a reaction to bug reports.
I think many of us know what the goal of Plots.jl is. The problem is the execution of the plan. Also I don’t think that many FRs get rejected/ignored because they ask for very specific use-cases. On the contrary, they usually ask for very basic functionality that is not working.
That is a good question @terasakisatoshi, and I think everyone contributing to Plots.jl currently had to learn the internal of the recipe system the hard way. Documentation can certainly help, but given the pace at which things are solved in Plots.jl, I guess you will have to learn it the hard way too.
Thank you for your advise!
I know Plots.jl is sooo wide and it will be a long journey to understand what is going on inside of Plots.jl Anyway I’ll dive into source code especially recipe.
A good way to start is to take the backend which whom you are most familiar with and check the issues that are open for it. Pick one and fix that.
Also don’t hesitate to reach out to us on the plots.jl stream in the julialang zulip, if you need help.