On 4/15/15 10:07 PM, Joakim wrote:
I understand that it's frustrating to get stuff done on a decentralized
open source project, but you have to help contributors a bit in order
for them to help you. Your [WORK] appeals have been a great step- I had
one of them open in my browser to remind me to get to it, but Walter
beat me to it- but the forum is not easy to keep track of and navigate
for newbies. How much harder would it be for you to stick all those in a
single wiki page, to make it easier for noobs to find and easy for us to
point them at? That's all I'm asking for. As far as I can tell, lists
and bugzilla labels have not actually been tried yet, so you cannot
dismiss them so easily.
As for the vision document, it was definitely a step in the right
direction, so that the community is clear on the vision of the BDFLs,
but it was a little less concrete than I would have liked. Back it up
with some concrete lists of issues for each vision item and it would go
a lot further, for example, what are the five bugzilla issues that would
most help improve quality of implementation? Without listing those,
it's just airy talk, missing specific steps you'd like to see taken.
Of course, you can go to all the trouble of coming up with a list of
action items and nobody outside the core group may still contribute, as
I said from the beginning. But if you don't make it easier for new or
non-core contributors, you just lowered the odds of them pitching in
from 7% to 1%. All we're trying to do is raise those odds, and I don't
think a list will take you or Walter much time, just like this one
deadalnix put up.
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.
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.
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.
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.
Andrei
