SDC needs you

[Joakim via Digitalmars-d]

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.