On Thursday, 16 April 2015 at 06:02:19 UTC, Andrei Alexandrescu
wrote:
This is good stuff. FWIW we do have a keyword "preapproved" on
bugzilla:
https://issues.dlang.org/buglist.cgi?f1=keywords&list_id=200200&o1=equals&query_format=advanced&resolution=---&v1=preapproved
It has 23 items of various ages. I didn't notice the presence
of the keyword helping in any way. So spending time annotating
issues with "preapproved" is possibly a waste of time. I
suspect maintaining lists of stuff to do is also low-impact.
Is this keyword documented somewhere easily accessible, like on
the wiki? If not, how do you expect someone new and looking for
a way to contribute to find it? I agree that it's unlikely that
someone will saunter in and learn the codebase and provide good
fixes in their spare time, which is why I remain skeptical of the
open source approach taken by the D community. But there are
ways to encourage more open source contribution, and prioritized
lists are one of them.
Yeah, we know what to do. A ton of it is easy to derive
directly from the vision, do I need to provide the food already
chewed? Eliminate gratuitous garbage from Phobos, create good
unique and reference counted types (and see if we need
something beside DIP25 to make them safe), improve associative
arrays (apparently there's no reasonable way to free an AA
manually...), documentation, documentation, documentation...
there's a bunch of stuff to do all over the difficulty
spectrum. It's painfully trivial to find easy and high impact
stuff to work on. That's not low-hanging fruit, it's fruit that
falls into one's lap.
The problem is that there's so much "fruit" in bugzilla that
someone new is overwhelmed. If they're not scratching their own
itch, how do they know whether the random issue they've chosen is
actually a priority? If you want to pull new people from outside
the core team, you need to provide them an easy way in, such as
an easily found, prioritized list from the core team, after which
they may realize it's not so hard after all, and stick around and
provide more. Yes, you're holding their hands initially, but if
it leads to the core team getting larger, that's well worth it.
Now that I got started, there are two more topics that I think
we could do a lot better at:
1. Challenging Walter on anything and everything seems to have
become a rite of passage in our community. Some of the reviews
of his code are the most petty and meaningless I've seen in my
career, bar none. It doesn't help that he doesn't budge on some
of the petty issues, thus a vicious circle gets created. In a
recent review, after his code had been pecked within an inch of
its death, it took me minutes to find two bugs that nobody had
the eyes for in spite of every token of his code having been
scrutinized.
I've been surprised by how much people challenge him on the
forums, seemingly ignoring the fact that he's been writing
compilers for decades. He's been very patient in explaining his
viewpoint on the forums, which is a big plus for the community,
though it would be better if he didn't have to repeat himself so
many times.
2. Turning the hay over and over and over again. I've mentioned
this before - there's just an astounding amount of tweaking and
shuffling and moving around code that works well under
serious-sounding pretexts such as "refactoring" and
"maintenance". Sometimes really difficult stuff, too. A lot of
it is low-impact work that makes Phobos' codebase look horribly
overcooked. There's been more than one instance when I
revisited some file I knew most of the code of. Elegant
solutions. Nimble code. Just to find it mutated into the stuff
of Agent Smith's world. One horrible contraption layered on top
of another to the extent it's difficult to find where work is
being done.
There is a way out of this, and that for us all to give good
examples that demonstrate what good contributions are and what
good reviews are.
Sure, and lists of priority issues can even emphasize to the
current contributors which high-impact work you feel should be
done first.
You have pointed out which direction you want the community to go
in the vision document, but some of those are too broad, ie
"improve quality." Stick some meat on those bones, by providing
a list of issues you feel would move those agendas forward, and
you might get the language moving further in your direction.
