March 14, 2014
On 3/13/2014 9:05 PM, Andrei Alexandrescu wrote:
>
> What would make the amounts interesting?
>

Just taking a stab in the dark here but...greater numbers are probably more interesting numbers? :)  (Sorry I can't be more helpful/specific than that.)

March 14, 2014
On 3/13/14, 2:45 PM, Leandro Lucarella wrote:
> Is still better than nothing, and at least a nice gesture to the
> community, but definitely not bounty-driven development :D

Probably we don't want that anyway. Where I'd hope to get is a point where bounties increase participation and dynamism, and steer work toward certain issues.

Andrei


March 14, 2014
On 3/13/14, 6:14 PM, Nick Sabalausky wrote:
> On 3/13/2014 9:05 PM, Andrei Alexandrescu wrote:
>>
>> What would make the amounts interesting?
>>
>
> Just taking a stab in the dark here but...greater numbers are probably
> more interesting numbers? :)  (Sorry I can't be more helpful/specific
> than that.)

Yah, I meant HOW MUCH would make the amounts interesting?

Andrei

March 14, 2014
On Friday, 14 March 2014 at 01:05:08 UTC, Nick Sabalausky wrote:
> Still, that's more than the $0/hr for most of the D contributions we're happy to do, so I'm not complaining.

Aye, but it doesn't push you over the line from "I'd like to do this but am too busy with other work" or "meh i don't care enough" to actually doing it.

I suspect one of those two states cover the majority of people who can but don't fix many D bugs today.

So while the bounty might be a nice bonus for those who were already planning to do it anyway, it is unlikely to lead to any *new* bug fixes; the rate of bug closure before and after probably hasn't changed (I'm sure we could measure this too to confirm my gut feeling).
March 14, 2014
On Friday, 14 March 2014 at 01:19:11 UTC, Andrei Alexandrescu wrote:
> Yah, I meant HOW MUCH would make the amounts interesting?

That's hard to say, but something around 5x larger would be enough for me at least to start doing D bugs instead of taking more PHP contracts - that'd put the bounty into decision /shaping/ territory instead of just being a bonus on top of an already-made decision because then it might be a viable sum of money to cover my bills in the time it takes to do it.

Though, of course, if it sits idle in the review queue for a year, that'd be a problem too.

I think a good move regardless would be to write up the review criteria and link them right from the readmes so authors know what they'll be expected to do and reviewers know what to look for. Then new reviewers can come on and just follow the procedure instead of deferring to the (already overloaded) handful of people who know what to do in their heads.

This isn't a bad start:

https://github.com/D-Programming-Language/phobos/blob/master/CONTRIBUTING.md

but could use a lot more fleshing out
March 14, 2014
On 3/13/2014 9:23 PM, Adam D. Ruppe wrote:
> On Friday, 14 March 2014 at 01:05:08 UTC, Nick Sabalausky wrote:
>> Still, that's more than the $0/hr for most of the D contributions
>> we're happy to do, so I'm not complaining.
>
> Aye, but it doesn't push you over the line from "I'd like to do this but
> am too busy with other work" or "meh i don't care enough" to actually
> doing it.
>

Depends how well one's day job is going ;) And I do think it *can* be enough to tip the scales if someone is tempted but not entirely comitted - the final straw to say "Ok, you know what, I think I *will* take a shot at that after all".

But I think you may be right that it isn't exactly going to get a bunch of people clamoring over "Ooooh!! I'm gonna go fix that one!!" As far as what *would* to that though, I really don't know (I mean, beyond obviously silly answers like "Three million!").

FWIW, I think there *are* dangers in going too high with the bounties (and I can't believe I just said that ;) ). Don't want to end up with contention over who gets a bounty (esp if people had already made significant contributions towards something, and then a bounty gets posted and someone else swoops in for the last little bit). Also don't want to discourage people from bothering with non-bounty issues.

March 14, 2014
On 3/13/2014 9:19 PM, Andrei Alexandrescu wrote:
> On 3/13/14, 6:14 PM, Nick Sabalausky wrote:
>> On 3/13/2014 9:05 PM, Andrei Alexandrescu wrote:
>>>
>>> What would make the amounts interesting?
>>>
>>
>> Just taking a stab in the dark here but...greater numbers are probably
>> more interesting numbers? :)  (Sorry I can't be more helpful/specific
>> than that.)
>
> Yah, I meant HOW MUCH would make the amounts interesting?

Heh, yea. The best I can say is this: My gut feeling (aka best guess, emphasis on "guess") is the general ballbark for "interesting" would be something comparable to a person's salary/wage for whatever amount of time the work would be expected to take. Ex: something that would probably take one full workday's worth of work would be interesting at approx whatever their day job's salary works out to per workday.

Admittedly, that's a pretty vague answer, too.

March 14, 2014
On 3/13/2014 2:40 PM, Vladimir Panteleev wrote:
>
> The only Phobos one is the std.getopt one, however its situation is two
> abandoned patches and no clear goal as to what constitutes a change
> worthy of marking the issue as "fixed" and paying out the bounty.
>

Yea, this is actually a general issue I think needs addressed. Some of the bounties can be quite unclear on what exactly is expected in order to fulfill the bounty's requirements.

The waters are muddied even more when other people have already made progress towards closing the issue (ex: All the years of work Don's already put into "[CTFE] copy-on-write is slow and causes huge memory usage").

I find there's bounties I'm more inclined to avoid just because I don't want to step on anyone's toes. Or because if I do X and Y for a bounty, I don't want to and worry about putting the bounty's backer in an awkward position, or accidentally looking greedy, just because there was also a Z I didn't know was expected (or maybe a performance improvement wasn't *enough* of an improvement) just because the issue wasn't well-defined.

But maybe I'm just being socially paranoid?

March 14, 2014
On Friday, 14 March 2014 at 01:16:57 UTC, Andrei Alexandrescu wrote:
> Probably we don't want that anyway. Where I'd hope to get is a point where bounties increase participation and dynamism, and steer work toward certain issues.
>
> Andrei

From my point of view, bounties won't be super efficient as attracting newer people, now matter how much money you put in it.
From my perspective (soon-to-graduate student), there's lot of people that would like to participate to an open source project, but don't have the knowledges yet. Those who have are already involved anyway.

Stepping in OSS code can feel like facing a giant behemoth, and getting familiar with a project, it's short/mid/long term goals, practices, do and don't is not easy, especially with D (a good example is the final-by-default discussion, where Dicebot pointed the schedule, while you were opposed to it, and most didn't knew about).

Most of the issues are DMD issues. I wouldn't mind some extra bucks, but I know that getting familiar with DMD and bugfixing it will be far more rewarding that the $100 I could make. It would extend my knowledges and in the same time give me some code to show to a future employer.

In addition, I also know that it will be a long time before I can solve any of the bug, as they require a lot of experience / knowledge of D.

I think what D needs, to drive contributors in, is mentors. People that are displayed as "contact points" for people that wants to get involved.
Then in triage, some bugs could be marked as "Training" bugs: ie, bugs that could be easy to fix, but should not be solved by experienced contributors before a certain period of time, unless there is a real need.
This way, it would left the door open for "newbie" to step in, say they are interested in fixing the bug, and get a DMD guru to point them to the right way.

I think someone mentionned that in the "Broken" thread, but D could use a documented governance model (something like a simplified Qt open governance model).
March 14, 2014
On Thursday, 13 March 2014 at 18:40:01 UTC, Vladimir Panteleev wrote:
> On Thursday, 13 March 2014 at 18:20:16 UTC, Andrei Alexandrescu wrote:
>> https://www.bountysource.com/issues/1325905-shared-phobos-library-doesn-t-work-on-all-linux-distributions
>>
>> Over $2000 in open bounties left:
>>
>> https://www.bountysource.com/trackers/383571-d-programming-language
>
> Looks like most of these are on compiler bugs.
>
> The only Phobos one is the std.getopt one, however its situation is two abandoned patches and no clear goal as to what constitutes a change worthy of marking the issue as "fixed" and paying out the bounty.

+1

> As for the compiler bugs... well, all of these are HARD, at least from the perspective of someone inexperienced with DMD's codebase. If they were easy, they'd have been solved already. DMD is not something you can easily dive into and start moving code around to fix big problems. Speaking from experience, it wasn't once that a 50-line patch would take me days to author and debug. And even if I were to manage through, the chances are high that the patch ends up crap because you need a lot of knowledge about how the compiler works to understand what's a good idea, and what isn't. Not even Kenji's pulls are always approved.

+1

It's hard to dive into dmd's codebase. And probably it takes a lot of time to understand it and to feel confortable enought to try some fixes.

Fixing phobos bugs probably is quite easier for a D user. You just need to know phobos and D to fix a bug and you don't need compiler-related topics. I think that in this case a small reward could fight the lazyness of users.