Help wanted identifying "good first issues" in scala/bug

Community
#1

there used to be a “quickfix” label, but (in part due to the JIRA -> GitHub move) it was incorrectly applied to way too many tickets, so it’s been deleted. (history/details on that: https://github.com/scala/scala-dev/issues/384)

there is now a GitHub-wide standard to have a “good-first-issue” label. so we have one now:

https://github.com/scala/bug/labels/good%20first%20issue

but at the moment, no issues have this label yet.

so, an invitation to the community. can you help us identify easy issues that are suitable for newcomers to open-source Scala work? (which also makes them suitable to veterans looking for something that won’t take too long…)

if you find a candidate issue, please comment on the issue and say “is this is a good-first-issue?” (or words to that effect), and someone with the access to attach labels will (hopefully!) label the issue for you.

or, if you have the necessary access, go ahead and label the issue yourself. (some community folks already have that access; if we’ve overlooked an established contributor, contact me)

Seth Tisue / Scala team / Lightbend, Inc.

#2

anyone with an interest how we could improve our management of the contents of scala/bug might like to read the discussion Guillaume (@smarter) and I just had about it at https://gitter.im/scala/contributors?at=5a78ee014a6b0dd32b934685

#3

Can new comers contribute to codebase or just documentation only?

#4

Can new comers contribute to codebase or just documentation only?

(I am not a scala/scala committer but) I think first-time contributors to scala/scala can contribute in codebase, not just docs.

The caveat is that with code changes, the bar of proving that the change didn’t break existing code is higher, so it would probably be good to start with somewhere that’s easier to show that. Non-collection library changes, such as adding a new method to Future, might be good places to start.

#5

I have contributed to scala/scala as a newcomer, so I can confirm that you are able to do it. I also agree with @eed3si9n’s advice.

#6

Another area for code contribution that is relatively contained is removing deprecation that happened in 2.12 or earlier. (https://github.com/scala/bug/issues/10033) For example, def a: A in Left is now deprecated in favor of def value. You still have to make sure that your test runs, and you might even get some pushbacks from the supporters of old code, but that’s something easier to start.

There’s also an issue for deprecating the parameterless @deprecated for those who like something meta. (https://github.com/scala/bug/issues/9079)

1 Like
#7

I’m happy to have a go at either. I can take look at removing deprecated code (10033) if that sounds good.

#8

I am happy to work on Future, and issue 9079.

#9

there are now 23 “good first issue” issues at https://github.com/scala/bug/issues?q=is%3Aissue+is%3Aopen+label%3A"good+first+issue" , which is a good start! thanks for those who have been helping with this. I’ll continue keeping a lookout for eligible issues; I hope others will as well.

we also now have the same label in both website repos:

#10

we’re up to 58 “good first issue” issues at https://github.com/scala/bug/issues?q=is%3Aissue+is%3Aopen+label%3A"good+first+issue"