Vision 2016 H1

[Joakim via Digitalmars-d]

On Monday, 25 January 2016 at 03:14:47 UTC, Andrei Alexandrescu 
wrote:
> In case you missed it from the announce forum: 
> http://wiki.dlang.org/Vision/2016H1 -- Andrei

Some comments:

- I'm not sure number of PRs is worth measuring, maybe a better 
metric would be number of devs submitting a PR, especially given 
your goal of raising participation.  If it's just a core group of 
devs submitting most of those PRs, does it matter much that they 
had more time to work on D a year ago?

- I don't think the language of military hierarchy, ie 
general/lieutenant/soldier, applies towards D.  It's more like a 
guerrilla army, think the US revolution and the Swamp Fox 
(https://en.wikipedia.org/wiki/Francis_Marion#Guerrilla_war).  
Since everybody is a volunteer, this is how it will be organized 
anyway, just pointing out that almost nobody wants to be called a 
lieutenant! :)

- It sounds like there's a fair amount of minutiae that's only 
handled by the core team right now.  I agree that formalizing 
that work into an official title or group would help get more 
people to do it, as has been done with the release manager role.  
On the other hand, every OSS project has this problem, as few 
will volunteer to take out the garbage. ;)

- Don't discount the debate on the newsgroup.  I lurked in the 
newsgroup for years before I got involved, to see what kinds of 
decisions were being made and how the process worked.  Yes, 
everybody would rather debate than chip in, but talking is 
usually a precursor for doing.

- I don't understand this section:

"This needs to be balanced with the false notion that any 
contribution must receive attention in proportion to the effort 
expended on it. 'I wrote a DIP therefore it must be worked on' 
quickly becomes 'There's no purpose in trying a DIP, nobody will 
look at it'."

Are you saying DIP and PR authors should not expect anybody to 
care about their efforts?  That would seem contrary to the goal 
of raising participation.

Perhaps a way to avoid this situation and formalize it would be 
to provide some sort of pre-approval process that is guaranteed 
to be checked by the core team (enhancement requests in bugzilla 
don't work, it's just too overstuffed with issues), so that 
contributors can be told _before_ they work on something whether 
it's likely to get serious consideration.  Maybe a wiki page 
that's monitored by the core team?

Swift also has the converse, a list of issues that are unlikely 
to be accepted:

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

- There's a couple mentions of tooling, but I don't get the 
impression that source formatters and parsers are what people 
have in mind.  I think they're talking about bugs or holes in the 
core tools, ie compilers, linkers, and debuggers.  This is a 
problem for any OSS project that doesn't have a commercial model, 
to fund such quality of implementation issues that volunteers 
don't want to take up.