# Standard "intro issue" label for all packages
**URL:** https://discourse.julialang.org/t/standard-intro-issue-label-for-all-packages/1538
**Category:** Community
**Tags:** package, proposal
**Created:** [January 17, 2017, 10:23am UTC](https://discourse.julialang.org/t/standard-intro-issue-label-for-all-packages/1538 "2017-01-17T10:23:38Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@waldyrious](https://discourse.julialang.org/u/waldyrious)
#### Post date: [January 17, 2017, 10:23am UTC](https://discourse.julialang.org/t/standard-intro-issue-label-for-all-packages/1538/1 "2017-01-17T10:23:38Z")
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](https://github.com/JuliaLang/julia/labels/intro%20issue) label (which is appropriately featured in [up-for-grabs.net](http://up-for-grabs.net/#/tags/julia)), 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](https://github.com/search?utf8=%E2%9C%93&q=is%3Aissue+label%3Abug+language%3AJulia).
If there’s support for this idea, I’ll make a PR adding this recommendation to the [package development documentation](http://docs.julialang.org/en/stable/manual/packages/#package-development), and maybe start prodding some of the most popular packages to start using it.
---
### Author:  [@oxinabox](https://discourse.julialang.org/u/oxinabox)
#### Post date: [January 17, 2017, 10:29am UTC](https://discourse.julialang.org/t/standard-intro-issue-label-for-all-packages/1538/2 "2017-01-17T10:29:54Z")
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.
---
### Author:  [@pkofod](https://discourse.julialang.org/u/pkofod)
#### Post date: [January 17, 2017, 10:59am UTC](https://discourse.julialang.org/t/standard-intro-issue-label-for-all-packages/1538/3 "2017-01-17T10:59:40Z")
> [@oxinabox](#):
>
> in general it is better for a new-comer to contribute to a package,rather than to the language itself.
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.
---
### Author:  [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)
#### Post date: [January 17, 2017, 12:10pm UTC](https://discourse.julialang.org/t/standard-intro-issue-label-for-all-packages/1538/4 "2017-01-17T12:10:18Z")
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])
---
### Author:  [@lobingera](https://discourse.julialang.org/u/lobingera)
#### Post date: [January 17, 2017, 8:00pm UTC](https://discourse.julialang.org/t/standard-intro-issue-label-for-all-packages/1538/5 "2017-01-17T20:00:37Z")
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.
---
### Author:  [@pkofod](https://discourse.julialang.org/u/pkofod)
#### Post date: [January 18, 2017, 8:34pm UTC](https://discourse.julialang.org/t/standard-intro-issue-label-for-all-packages/1538/6 "2017-01-18T20:34:36Z")
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.
---
### Author:  [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)
#### Post date: [January 18, 2017, 9:38pm UTC](https://discourse.julialang.org/t/standard-intro-issue-label-for-all-packages/1538/7 "2017-01-18T21:38:18Z")
> [@pkofod](#):
>
> 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.
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.
---
### Author:  [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)
#### Post date: [January 19, 2017, 1:31pm UTC](https://discourse.julialang.org/t/standard-intro-issue-label-for-all-packages/1538/8 "2017-01-19T13:31:50Z")
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)