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.
