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.
