Scaladex - Connecting Contributors with Projects (GSOC 2017)

My name is Michael Viveros and I am interested in participating in Scala’s Scaladex project for GSOC 2017. The main goal of the project is to find a way to better connect project maintainers with interested open source contributors by building on Scaladex.

Below are some potential solutions. Could you give me use some feedback about them as well as any other solutions you could think of?

Option 1 - Use a project’s keywords
Projects in Scaladex have keywords (Ex. akka, database, scalajs) which could be used to search for other projects with similar keywords whose contributors might be a good fit for the original project. This is a simple solution which uses existing features of Scaladex.

Option 2 - Add Contributor pages
This option would extend Scaladex to have Contributor pages in addition to it’s existing Project pages. A contributor’s page would have info about projects they’ve contributed to, keywords they’re interested in, … This solution will be more work than the first option but would be more powerful since it could connect contributors with projects that have keywords they’re interested in, even if the potential contributor hasn’t previously contributed to a project related to that keyword.

Those both sound like good approaches to explore, but one additional thought: those are both good for connecting people who have already contributed in some way, to help them find additional projects. The most interesting (and hardest) challenge, I think, is to find ways to help new contributors get started. People who are already deeply involved in the ecosystem often already have some idea what they want to do, but we frequently have people coming in, going, “I want to help, but have no clue how to get started!”

You may want to chew on it and see if you come up with ideas – anything that makes it easier for new folks to get involved in projects would be a huge win for the community. For example, a new bit of UI that allows projects to specifically list and describe enhancements they are looking for people to take on, links to this project’s Gitter discussions, and things like that.

Just to give a bit more context, this is the project description:

Connecting potential contributors with Scala projects via Scaladex
Scaladex is a cool new tool that maps out the known Scala ecosystem by connecting GitHub users, published binaries, contributor info, documentation info, and release info of Scala projects. The one thing though that Scaladex doesn’t do yet is connecting potential contributors to Scala projects that are on the lookout for contributors. Your task if you take on this project would be to find a way to better connect project maintainers with interested open source contributors, by building on Scaladex, a web application built with Scala and Scala.js.

So, the question is: how best can we help connect contributors and people interested in contributing?

1 Like

Another idea: some sort of needs-based keyword matching? Scaladex’ existing tag system is all about “what is this library good for?”. For project-matching, maybe an additional set of keywords/tags for desired skills/projects? I’m thinking keywords like “benchmarking”, “debugging”, and so on – general identifiers of what this project is looking for, so that potential contributors could filter based on the kind of thing they’d like to do.

Related: keywords for required skill levels, maybe? Amount of required Scala expertise in order to be able to contribute usefully? ('m just brainstorming here.)

Basically, I’m trying to put myself in the shoes of a new contributor, who wants to help but is intimidated by the sheer number of projects out there. How do we make it easier for this person to find a project that suits their skills and interests?

Oh, and from a purely practical perspective: if I’m a new contributor who wants to help project Foo, how do I actually contact the maintainer(s) of that project? That’s a non-trivial problem, especially for someone who is new to the Git ecosystem, since GitHub provides no good way to directly contact somebody. Nowadays I tend to use Gitter, but not everybody uses that actively. This is, I suspect, a real and serious problem we might want to look at…

1 Like

Apache has a Test people can take to help them find projects they can contribute to based on their skills/interests so a similar Contributor Test for Scaladex could be another option.

To build off this example, a project page could use the GitHub API to show a list of open, beginner-friendly Issues which could give a new contributor a place to start.

I don’t have an answer here but your concerns are actual issues I have hit in the past.

I have made a few, but not many open source contributions in the past and Scala has been the hardest for me to get going in, although the most rewarding over time.

Maybe it’s worth tweeting out asking people what there beginner hurdles were?

I’ll start in case others find it useful.

  1. Tried to open project in IntelliJ to start working on it just like I would my code at work. Doesn’t open in IntelliJ. Happens often, I think many beginners and 9-5 programmers use IntelliJ and many library authors do not.

  2. SBT test. Tests don’t run. Turns out there are special steps like publish local needed first not in

  3. Make a contribution! Hooray. No review. 3 months later, no feedback, feels like a waste of time but I remind myself I still learned something.

  4. Try to contact maintainer to ask how I can help, no contact info, no email, not on Twitter.

Would it be worth having a slightly non-standard file that scaladex could look for. I always look for and am excited when I find it. Maybe we make a tab that shows it like and if it contains certain tags highlight them somehow. Then we could encourage certain practices like your project will run run test green with SBT/CBT test, no special resolvers or publishlocal needed unless listed in the guide. Or a flag denoting compatibility with ensime, IntelliJ, maybe encourage a scalafmt config so people don’t have to wonder if they have the correct formatting.