Standard "intro issue" label for all packages

package
proposal
#1

It’s quite common for newcomers to the community to make a post asking about potential issues they could work on. Julia itself uses the intro issue label (which is appropriately featured in up-for-grabs.net), but there’s no such standard for the packages.

What do package authors think about adopting a “intro issue” label? With a unified label across the Julia ecosystem, such issues would be easily searchable with queries like this.

If there’s support for this idea, I’ll make a PR adding this recommendation to the package development documentation, and maybe start prodding some of the most popular packages to start using it.

#2

I think this is a particularly good idea because
in general it is better for a new-comer to contribute to a package,
rather than to the language itself.

#3

I’ve thought about this the past days, and I agree that newcomers who want to contribute should be encouraged to look at the existing packages or start a new one. I’m not saying JuliaLang couldn’t use more labor, but speaking for Optim.jl, the marginal product of an additional contributor is immense when you’re coming from one or two regulars.

#4

I think that’s especially true right now, with all the major changes going on in Base, that it’s harder for PRs (no matter how good) from new people to get the attention they need. (Hopefully that will calm down in a couple of months, as v0.6 gets released [or at least close to release])

#5

just my 2c here:

I like the idea to give out intro issues on packages also. Of course this has more impact on the more popular packages.

I’m not sure if i want to see the situation that newusers are encouraged to start new packages (public). We already have a long list of single-developer/almost-not-maintained packages around and some consolidation would be beneficial for the community.

#6

All right, that “new package” was more of a last resort kind of thing, but some people might be coming to Julia with expertise, and their best contribution might be to make a new package. Also, remember that this is OSS, not a job. Many people get their motivation and drive from working on their project. Sure, a lot of us get a small kick out of contributing to the “community”, but fixing three year old design mistakes in some big package with 1000+ commits is not for everyone.

That being said, I would love to see more energy going towards the existing packages.

#7

Same sentiment. As much as I’d like making existing packages better, some of the older unmaintained packages can just go. Someone who knows what they are doing should in many cases just re-create a whole package from scratch because somethings do need a do-over. And if someone is willing to do that, more power to them. We’re still pre-1.0, so it’s fine for creative energy to run amok and see what sticks.Even after 1.0, it’s an OSS community! No reason to pick winners just because they’ve been around longer.

#8

Sometimes though there’s a problem, in that some package that is 3 years old, and has barely been maintained since if at all, has taken the obvious name for something (especially given the guidelines that a package thats wrap the library FOO should be called FOO.jl).
There needs to be a way of doing some “spring cleaning” of the package ecosystem, especially before we get to v1.0.
(Hopefully there will be some features in the Pkg3 design to make dealing with this sort of thing easier)