Thought on the 2015H2 Vision Participation Goal

[Adrian Matoga via Digitalmars-d]

On Sunday, 15 November 2015 at 02:56:35 UTC, Charles wrote:
> Hi everyone,
>
> Just looked at the vision for this half, and I had an idea pop 
> in my head. Before I get to that idea, let me explain what I 
> think might be an issue with it as-is.
>
> I've consistently seen D's participation metrics marked by the 
> number of pull requests created and closed, which is great. 
> This gives us input as to how active people are on actually 
> developing the core part of D. Unfortunately it doesn't give us 
> an indication as to what caused this number to increase. Was it 
> new users? Was it people becoming more familiar being more 
> productive? Etc. While I don't doubt participation is 
> correlated to pull request counts, I don't think its a great 
> indicator of new users.
>
> Furthermore, I don't know if this can scale. We get small 
> dedicated group capable of taking out 3-5 issues a month each, 
> and where does that leave us? With a lot of issues open 
> probably. How do we fix that? Ask the small dedicated group to 
> take more time out of their, presumably busy, life and fix our 
> problems for us.
>
> # So what should we do instead?
>
> Why not try and target people who haven't worked on a language 
> previously that are interested in doing so, but don't know 
> where to get started.
>
> I definitely fall into this group. I know there's something I 
> could do that would be useful, but I don't know how to find it 
> to get it done. I just wish there was something out there that 
> literally baby stepped me through the entire process. Yeah, I 
> might not be tackling extremely difficult problems right out of 
> the gate, but if there was even 20% of our issues that the only 
> thing holding them up is a lack of someone assigned to them, 
> this could be a huge win for everyone.
>
> # What could we do to accomplish this?
>
> Here's where I think that reorienting the goal actually makes 
> the goal a lot more manageable. At the cost of efficiency now, 
> what I (and presumably people like me) need are those baby 
> steps. Ideas could include:
>
> * A video about setting up their environment from scratch. This 
> is presumably 1 time thing for most users, but honestly one of 
> the easiest ways to get discouraged. If you're on your own for 
> this it instantly feels like you're going to be on your own for 
> all of it. It really shreds any notion of a community working 
> together. Because of the experience this can cause, and the 
> minimal amount of time that's required to do this, it should be 
> a no-brainer.
>
> * Flags for issues that are based on expected completion time 
> for someone reasonably competent with D. As a newcomer, I might 
> not know how involved an issue is. E.g. I don't mind spending 
> 1-3 hours this week, but *every* issue looks like it might 
> unravel on me and take a really long time.
>
> * Live code reviews where there can be feedback from experts on 
> how to approach things in a D oriented way. The forums work 
> great for getting a quick answer on something, but a lot of 
> times newcomers don't know the correct question to ask. This 
> kind of interaction is also extremely marketable... look at 
> Jonathan Blow with Jai, and he isn't even letting people use it 
> yet.
>
> People interested in helping out with this kind of project need 
> to learn somewhere... why not D?
>
> TL;DR: Change our participation goal to be more oriented 
> towards force multiplication. I question whether PR activity is 
> a sustainable metric.

I generally try to avoid participating in discussions about what 
could or should be done if I'm not sure I'd be able and willing 
to dedicate some significant amount of time to actually implement 
the idea, but [1] has recently been quite successful in bringing 
a few guys in my team at work from "not knowing anything about 
kernel programming" to "having an idea where to start if I need 
to do X", so I decided to mention it.

A similar set for D could go from trivial "download the sources 
and build the compiler" to eventually fixing the real issues from 
bugzilla.

[1] http://eudyptula-challenge.org/