Concerning the policy, I think the transfer of the packages to organizations is the best everyone can do. So its easier to maintain them functional even if the authors are too busy to merge updates.
12 Likes
To summarize, the actual practical problem, of that package, or its docs, has been solved (a PR was merged in 11 min, so 2 years old package became brand-new…).
Still thanks for bringing up the general problem, i.e. need for a policy. Maybe one is not actually needed (see also discussion on it and my advice of a workaround when there’s a, possible, no longer working code) if you could rely on such fast response… Yes, you can’t rely on such quick answers always (for any language, though it often happens in Julialand), or PR merged.
I’m not sure what you mean. Of that package or Julia itself? No that’s great in either case.
3 Likes
Authors can be alerted to out-of-date or incorrect documentation if they use doctests to run the documentation examples automatically. I would like all documentation examples to be written this way.
3 Likes
I would think that with doctests and documenter, you probably have a local environment for the docs where the version is then fixed again for those packages used.
Then you would need a way to get alerted when new package versions are available (like CompatHelper).
2 Likes
Well, if you face an issue just ask here in the forum. And if that is not sufficient create an issue in the package you want to use, Both is easy if you have an example that reproduces the problem. 
3 Likes
It’s never a mistake to donate to causes you support! As @Palli noted, did you sponsor Julia itself or the specific package author(s)? Much like how the core Python language developers do not control every single Python package, the core Julia developers do not work on every single Julia packages. So donating to “Julia” is great! It will help the team make the language better overall (a win for everyone!), but it probably won’t get someone to work on a specific package.
But as you can see the Julia community is great! You posted a problem, @lmiq made a PR and the maintainer merged it within 24 hours! So the takeaway for me here is that it can (not always) be quite easy to take a dusty old package, shine it up with a couple of fixes, and have something ready to go. Realizing of course that it might take a little extra effort from the user.
6 Likes
There’s a bit more defensiveness in this thread than I would like to see, but the bottom line seems to be that despite not being updated for a couple of years, SmoothingSplines does still work as intended on both old and new Julia versions. The issues running the example come from breaking changes in another package, DataFrames, which has undergone significant development work in that time, but has now stabilized and will no longer have any more breaking changes (until such a time as DataFrames 2.0 becomes necessary). I think that we can conclude that there isn’t any package neglect here. SmoothingSplines still works and DataFrames is the opposite of neglected. The only thing that was broken here was a documentation example, which has now been fixed. While broken examples in docs are certainly a drag, they’re hardly unique to Julia.
Support for projects is always appreciated but not by any means expected, please don’t feel that you have to donate in order to report issues. Refraining from jumping to a conclusion of something so dramatic as “neglect” until it is clear that’s actually the case seems prudent, however. A less dramatic way of putting this would be “This example doesn’t work, any idea why not?” This could be done on discourse or by opening an issue on the package.
41 Likes