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/
