How to make it easier for everyone to contribute to Elixir

[José Valim]

Hello everyone,

Today I was wondering how we could make it easier for everyone to contribute to Elixir.

Either for people that have already sent a pull request and those who have not.

So what I would like to hear is:

1) Have you already tried to contribute but got stuck somewhere? How could we help? Any particular aspect on this requiring more documentation?

2) Currently we have a bunch of open issues in the issues tracker. Some of those are low hanging fruits. If I tagged those issues on Github, would that help people looking for easier to tackle issues? Is classifying issues per "perceived difficulty" a good idea?

Curious to hear your thoughts :)

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Lead Developer

[Bryan Summersett]

I would appreciate having "easy to tackle" issues tagged, if it's not too inconvenient. It wouldn't need to be comprehensive.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Dave Cottlehuber]

> On Tue, May 14, 2013 at 3:24 PM, José Valim
> <jose....@plataformatec.com.br> wrote:
>>
>> Hello everyone,
>>
>> Today I was wondering how we could make it easier for everyone to
>> contribute to Elixir.
>> Either for people that have already sent a pull request and those who have
>> not.
>>
>> So what I would like to hear is:
>>
>> 1) Have you already tried to contribute but got stuck somewhere? How could
>> we help? Any particular aspect on this requiring more documentation?
>>
>> 2) Currently we have a bunch of open issues in the issues tracker. Some of
>> those are low hanging fruits. If I tagged those issues on Github, would that
>> help people looking for easier to tackle issues? Is classifying issues per
>> "perceived difficulty" a good idea?
>>
>> Curious to hear your thoughts :)
>>
>>
>> José Valim

Good move José.

Some suggestions:

- make CONTRIBUTING.md a link from the main website, or even have its
own page -- easier to find
- add some info about pre-work you should do - tests passing,
formatting code a certain way etc
- give a link to 2 or 3 ideal PR or commits that show these things in
a clear consistent format
- make it clear that people can have a go and get some positive feedback

There is a marked difference between cultures and invididuals about
how much permission they feel they need to get started on things, and
huge variation in FOSS projects about how contributions are received.
My canonical experiences are perl and openbsd communities. I found
elixir and erlang projects very open and supportive, this is not as
common as one would like!

Currently my constraint is time, not much you can help with there :-)

A+
Dave

[meh.]

> 2) Currently we have a bunch of open issues in the issues tracker. Some of
> those are low hanging fruits. If I tagged those issues on Github, would
> that help people looking for easier to tackle issues? Is classifying issues
> per "perceived difficulty" a good idea?

I would like that a lot, I mostly just contributed with additions, but
bugfixes would be interesting too and some direction for that would be
awesome.

[Jeremy Huffman]

I found it very easy to contribute the small things that I have, and it was very encouraging that the PR were merged very quickly and were appreciated. I think those are among the most important things to do to encourage this.

For myself, I have to say that when I do look at the issues list, I don't see much that I could take action on. Most of the issues are opened by people who are already more knowledgeable than I. The open issues seem to only stay open if they need more discussion, or if they are very tricky to solve or otherwise present a challenge that I lack the confidence to propose a specific solution for.

So yes, I think tagging the low hanging fruit as such would help people be helpful. Maybe sometimes an issue is really more straightforward than I can make out from the description.

--

[Gustavo Brunoro]

I'm still getting my head around Elixir and haven't contributed yet, but #2 (tagging the low hanging fruit) would be a great way to encourage contributions.

It'd be also helpful to have canonical examples of what's considered good practice on the community in terms of code style, commits, tests, documentation, etc.

2013/5/15 Jeremy Huffman <jer...@jeremyhuffman.com>

[José Valim]

Thanks everyone for the great suggestions!

We have improved the Contributing.md based on your feedback and we have categorized and tagged some issues by level on our issues tracker. What do you think?

Also, if you have any question about how to solve some particular issue or help with the implementation, feel free to ask directly in the issues tracker!

> The open issues seem to only stay open [...] if they are very tricky to solve

I believe this is no longer true. A couple months ago I was able to keep the number of open issues very low but not anymore. :) And with more and more people using Elixir, we will probably see more bugs, discussions and proposals to smaller improvements.

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Lead Developer

[Alexei Sholik]

> It'd be also helpful to have canonical examples of what's considered good practice on the community in terms of code style, commits, tests, documentation, etc.

The general advice is to look at Elixir's code, commits, tests, docs, etc. We don't have defined guidelines for those, so everyone basically looks at the code that's already there and adopts the same style.

Best regards
Alexei Sholik

[Gustavo Dutra]

I think label issues by the level it requires to close it would be awesome! There some bugs there that I can handle, others I don't feel confortable in touching. Algo, I've read a lot of emails telling that 'Getting Started' guide is not that good. I've been writing somethings I've learned. I've writing small things, like "prefer using guard conditions instead of using if/case".

Would it help if I add an issue with a list of things (and a list we can make bigger with user feedback) that we should add to Getting Started ?

[José Valim]

Would it help if I add an issue with a list of things (and a list we can make bigger with user feedback) that we should add to Getting Started ?

Definitely! Please feel free to open up issues on elixir-lang.github.com or even send pull requests directly. :)

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Lead Developer

 

Em terça-feira, 14 de maio de 2013 19h24min01s UTC-3, José Valim escreveu:

Hello everyone,

Today I was wondering how we could make it easier for everyone to contribute to Elixir.

Either for people that have already sent a pull request and those who have not.

So what I would like to hear is:

1) Have you already tried to contribute but got stuck somewhere? How could we help? Any particular aspect on this requiring more documentation?

2) Currently we have a bunch of open issues in the issues tracker. Some of those are low hanging fruits. If I tagged those issues on Github, would that help people looking for easier to tackle issues? Is classifying issues per "perceived difficulty" a good idea?

Curious to hear your thoughts :)

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Lead Developer

--

[Carlos Galdino]

Joe,

about #1, I think GitHub already does a decent job about it. You can click the `Edit` button and that will automatically fork the project and you'll be able to edit it online without having to go through all the other steps by yourself.

--

Carlos Galdino

On Fri, May 24, 2013 at 6:43 AM, Joe Armstrong <joe...@gmail.com> wrote:

Re contributions:

  I think you should distinguish small changes from big changes.

1) small changes

   Suppose I see a typo in the documentation. 

   a) I read the documentation on-line

   b) I see a spelling mistake

   c) I select the text in the browser - right click the mouse

       enter the correction

   d) the author is informed.

   e) the author brings up the documentation page - sees the proposed change

       clicks accept

(point c - you might want only authorised users to avoid spam - say login via trwigger/gmail.facebook and oauth)

The barrier for entry for a small change should be very small. If I want to contribute by

correcting a single typo let me do so with minimal overhead.

Don't make me do a seven step process in github for a trivial change - I just won't do it.

Seven steps is far too big a barrier. If you spelt function wrongly (say fonction) I don't want to do

git push/pull/patch/ bla bla blas - just correct it and click.

(Actually this might sound easy - but it's actually a lot of work - you need

oauth2, a web server a database and some javascript magic - but it's a worthy goal)

2) Big changes

    git hub push/pull/patch/merge/ is fine - painful but it works

/Joe