Thought on the 2015H2 Vision Participation Goal

[Charles via Digitalmars-d]

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.