• Charles (60/60) Nov 14 2015 Hi everyone,
• Adrian Matoga (12/73) Nov 15 2015 I generally try to avoid participating in discussions about what

Charles <csmith.ku2013 gmail.com> writes:

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.



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.



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.

Adrian Matoga <epi atari8.info> writes:

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.



 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.



 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/