A simple way to make the discovery of related packages easier is to have a section in the Readme that links to julia packages that solve related problems, or that may be of help to users of your package. I’ve tried to do this for a new package i’m working on here.
2 Likes
Hello @helgee, I’ll take this statement in general and it makes me wonder if the entry hurdle for future Julia users won’t be even higher? The user is using a package and the included functions are not stable and are not maintained properly → this will frustrate the user and he will stay in his old environment (e.g. R, Python or …). I’m afraid that this is what happens when the thought “… the fittest survivor!” is followed without the quality thought discussed so far. 
This is not a concern in practice, as Julia is more addictive than cocaine. Once you use it for at least a couple of months so that you can experience the issue your describe, you are hooked forever and never switch back.
You will make PRs to get your fix (it is no coincidence that Github recognizes the word). Start your own packages, and contribute to Base and the standard libraries, review code for strangers. It is a road to perdition.
15 Likes
Fittest in my mind is the package with the highest quality and by that I do not necessarily mean code quality. Quality of the documentation and the interactions with (potential) users is much more important.
The users will generally gravitate towards the package with the best docs and best discoverability (website etc.).
5 Likes
Just a couple of comments on some thoughts so far.
While I agree that creating a standard of any sort is likely to flop if it is a completely democratized effort, that shouldn’t mean there is no effort to collaborate. Others have already pointed out that projects started and steered by a single individual are more likely to be more successful. I think this is mostly true in the early stages when many decisions need to be made and needless bickering over tiny details immobilizes any progress. As the project grows that leader typically needs to step back and let the community manage a fairly stable ecosystem. This takes someone passionate enough to put in the work upfront, but humble enough to gradually let go of complete control. I guess what I’m trying to say is that there’s no perfect solution for this because you really just need an expert in a field to take lead of an ecosystem and also act appropriately as the leader of it. Also, I’d hate for people to see this discussion and decide not to collaborate when they have a great idea and it doesn’t immediately fit within the framework of relevant ecosystems that already exist.
As far as the CRAN Task Views goes. I’ve mentioned it several times here (or maybe on slack). We’d need to decide where it’s hosted/maintained and then how to structure it. Should JuliaComputing, julialang.org, or some other entity host this? Otherwise we may as well have individual Github organizations that host some sort of documentation outlining this.
3 Likes
Related to the discoverability of packages, a search operation (perhaps with semantic capabilities) for Pkg would be useful. Something on the lines of:
(~v1.x) pkg> search embeddings
Search results:
- Embeddings.jl (vX.Y.Z) https://github.com/JuliaText/Embeddings.jl
Description: Functions and data dependencies for loading various word embeddings (Word2Vec, FastText, GLoVE)
- EmbeddingsAnalysis.jl (vX.Y.Z) https://github.com/zgornel/EmbeddingsAnalysis.jl
Description: A package for embeddings processing
....
2 Likes
I have created a prototype for such a search function a long time ago before v1.0 was released, but my pull request to Pkg was never merged:
3 Likes
Oh nice. The discussion is pretty insightful as well. That PR should be updated, search is a nice to have feature. I’ll look a bit into it.
1 Like
REPL search for packages would be a great addition!
It can also have some kind of rating system for the packages based on, for example, GitHub stars, and test coverage and status. With this, the users can have an initial feeling about the package quality.
2 Likes
As someone who is fairly new to Julia (but a 120% convert), I made my first open source contribution ever by updating VML.jl.
This taught me a great deal about software development, but also was not a smooth experience.
It look months for my pull request to be merged, and we are currently waiting over a week to change the repository name to finalize a rename that lets us conform with the package registration guidelines.
I do not want to criticize the owners of the organization, many of which I see contributing everywhere in the Julia universe. It is simply not clear to me how to get “organization admin things” to happen, and who to contact.
Maybe as a first step every organization should have a website, which lists someone(s) in charge of managing it (adding contributors to packages, especially when they are abandoned, adding packages to the organization, …)
E.g. the JuliaMath organization only lists “julialang.org” as its website, and JuliaOpt has a website, but not specific mention. It even mentions that JuMP extensions should be discussed with the JuMP developers, but not who they are or how to contact them.
8 Likes
JuliaOpt has a website, but not specific mention. It even mentions that JuMP extensions should be discussed with the JuMP developers, but not who they are or how to contact them.
This is good point that we have overlooked.
We generally assume that people will post on the discourse sub-domain: Optimization (Mathematical) - Julia Programming Language
We do have a Google groups email for the steering committee. I’ll ask about sharing this publicly on the website.
2 Likes
On the one hand, these sentiments are related. My day job (academic scientist) depends on what I get credit for, and I have colleagues that have had ideas and even actual work stolen.
On the other hand, I think this is probably less of an issue in open source projects where an anyone can look at the commit history. People who do the work can make a strong case for getting credit for it.
That’s miserable! Good collaborations are definitely tough to find - hopefully your experience with AnalysisWorkflows/MrPhelps/Hapi is different. I do plan to help out with more than words eventually, honest!
EDIT: wow - didn’t realize how much this thread had exploded since I last looked… Sorry for referring back to ancient news 
2 Likes
Kevin, if you want we can move the analysis/haapi repo to your github if it would help your career. It will not help mine, trust me what I do at work is so unrelated its not even funny(that’s why I can do that project), but it’s fun so far.
1 Like
I am thinking back and forth about whether I should prolong the discussion with another post. Many things were discussed and I would like to come back to the quality indicators. They should directly point out the quality of the package to the user and make a decision of use easier. After all, achieving a high ranking is certainly an incentive. Let me make a visual suggestion (Flux is just a value-free example):
2 Likes
“82% of customers would buy again” 
2 Likes
Personally not a fan of quality indicators like this. Number of open issues is a bad proxy at best, and x out of 5 star reviews might deter people from publishing packages altogether, even if the quality would be fine.
15 Likes
Indicators, of whatever kind, naturally carry a certain risk of being misinterpreted. In my view, certain criteria are needed to improve the quality of the packages. This certainly contributes to the distribution and use (also in the commercial sector). Many things have already been discussed here. To your point …
… and x out of 5 star reviews might deter people from publishing packages altogether, even if the quality would be fine.
… …I wrote this six days ago:
Anyone can provide what they want via Github. The user therefore bears the risk. But if a package is listed on the Julia documentation page, it should meet certain requirements.
But this is my last post on the subject, I swear! 
I suppose a mention of the discourse as a way to get in contact would already be enough.
For the unlikely, but possible, scenario that someone has started working on something but has not been actively looking at this discourse.
1 Like
Great start - prior (and opensource) art addressing the same issue is ToolBox - know your options with available code base and catalog.
The jlenv took up the time I had last year, but I had a Julia port of those projects in mind - I’m pretty sure the effort of adding Julia data to those projects is one or two orders of magnitude smaller than starting from scratch…