Should TPF put up bounties (look at the projects accepted for last year's Summer of Code project)?

Yes.

Should no one be able a pumpking without the ability to do the job on a full-time basis?

See Perl Grant Approved: Improve Perl 5. Not sure if it's full time, but it's a start.

Should there be some vote among the users of Perl as to which features are important in a release?

Yes, though that "value" needs to matrixed against "difficulty". High-value and low-difficulty features should be first priority.

Another interesting idea could be to have users "vote" with dollar donations to TPF that are earmarked and held in escrow as the bounties from the first idea. That would quite directly determine the market value users place on having certain bugs fixed or features delivered.

While these ideas sound nice, we need implementation details. The one thing that many folks fail to appreciate is how incredibly difficult it is to get things done with volunteer labor and a shortage of such labor, at that. Good ideas are often scrapped as impractical. Let me give an example.

I'm the secretary for the TPF Grant Committee. When I took over that role, one of my first priorities was to make the grant system a bit more accountable. Part of that was publishing regular updates to the TPF blog and ensuring that we were following our charter scrupulously. However, another process that needed to be changed was to not pay out all the grant money up front in hopes that the work would get done. Here's what would be nice:

• Regular milestones would be identified and published.
• The grant manager would discuss/negotiate every month with the grantee what work was accomplished and only pay for milestones achieved.
• If milestones needed to be changed, the grantee would rewrite them and submit them for approval.
• Checks/wire transfers would go out monthly for this.

Why was something so simple not adopted? Because frankly, most grants are for far less money than the actual project is worth and grantees would be mired in paperwork and endless discussion. Already we've had people decide not to go for a grant because it's not worth their time, so increasing the hassle of a grant makes the problem worse. In short, we have trouble paying people to get work done, much less getting enough from volunteer labor. (From what I've seen, as a rough rule of thumb you can multiply many grants by 4 or 5 to get an idea of what they are really worth -- people need to pay mortgages/rent and they're not getting rich off what we can afford to pay).

The compromise we reached needed to ensure that we were being proper stewards of the community's donations, so we agreed to "half up front, half on delivery". We realize that many folks will want a more stringent process, but we only have so much time and money, so we did the best we could.

This is only a tiny example of many decisions and compromises which need to be made to keep things rolling along. It's not easy, but we try. Short of a massive influx of money or volunteers willing to work for free, we have to struggle with what we have.

As for having funds put in escrow for particular projects, we have done that for large amounts of money, but managing a bunch of smaller escrow amounts would be problematic due to lack of enough free time on the part of volunteers. This is also what killed a nice "micro grant" project which was discussed. We just haven't come up with a way of making the process relatively painless. If you have some ideas on how we can implement this, I would dearly love to hear them.

Cheers,
Ovid

New address of my CGI Course.

I really do appreciate the complexity. I thought about it after my post, particularly about verification of delivery -- it can't just be "bug closed" on the RT. My best idea so far is to agree up front on a test script and the platform(s) on which it must run. If the script passes, the coder gets paid. Incremental payments can come when X% of tests pass. While writing the test script takes effort, too, that's another way of triaging the most important items to address -- i.e. the ones where someone is motivated enough to write a good, testable spec.

And while I get that this is complex, nevertheless, when US comp-sci students can outsource their homework to RentACoder for under $100 a shot, I've got to imagine that there's some existing infrastructure that could facilitate micro-payments for small, focused pieces of work. (And I'm not saying it's rentacoder.com, per se, I'm just using that as an example of the kind of infrastructure I mean.)

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Paying people to do things is fine, but probably the most expensive way to get things done. At the end the contributor will not see the money as a reward but as a payment for his work and so request money accordingly.

On the other hand you have lots of volunteers that are contributing their time just because they like to do so. They are the cheapest way to get things done. Maybe with a little money you can reward them in some way, making them feel an important part of the project and the community, happier, and willing to contribute more.

For instance, send T-shirts, stuffed camels or keyrings to people contributing paths, to the best CPAN uploads of the month, etc. For important contributions, you can give better prices as watches, silver or gold pins, etc. or invite them to some conference.

Other possibility is using your influence to help them, for instance, give them some award they can include on their CV or keep a labour exchange website or just a who is who web.

Personally, I've tried to stay out of the whole perl 6 debate. Not because I'm not excited about it. But because I simply don't have the time to provide meaningful contributions (I tried getting haskel working on my gentoo box, it failed to compile, I haven't had time to figure out why, so I tossed it, preventing me from even looking at writing test cases, failing or not). Contributions can be either time or money - and I don't really have either to give.

So when I saw all those complaints about how long perl 6 is taking, it was, well, annoying. Annoying in that perl 6 is perfectly on topic here, and easily ignored, yet wasn't (although I ignored it in that thread by not responding to fuel it). And, as the saying once went, "put up or shut up." Either put up the time and/or money to help, or leave well enough alone. Even assuming that anonymonk is right that perl 6 is a pipe dream, never to be finished, how exactly is that harming him/her? Because they aren't spending their time on perl 5? Sorry, but their free time is theirs to spend, not some anonymous whiner. I won't be so presumptuous as to tell Larry what to do with his time that I'm not even paying for. Now, if I had the money to buy Larry's time (and he was willing to take it), then I could ask for more time and effort spent on perl 5. But I don't have the money, don't have interest in asking even if I did, and am not even sure Larry would take such a job.

So, of your suggestions, the bounties sound reasonable (putting TPF's money where its mouth is to improve the state of perl), and the vote sounds reasonable (as long as it's non-binding on anyone who isn't being paid to develop perl5, and probably not even on any who are being paid for it). But the others seem unreasonable and uncouth: it's their spare time they are so generously donating to the rest of our productivity, it'd be even more arrogant than Hubris calls for to demand of them absolutely anything other than what they want to give, and how they want to give it. Of course, once certain features/bugs/whatever are voted on, I'm sure someone will go looking for itches to scratch and be enticed by the extra brownie points garnered by tackling a highly-popular itch. But that's no guarantee.

As for xdg's "high-value and low-difficulty" criteria - I feel like this is just as presumptuous. Having a list of things we'd like to accomplish as a community is one thing. Ordering it by perceived value is another (voting is good for that). But putting volunteers on things that they have no interest in is less than productive, and probably demoralising. (Money, of course, can be an interest...)

As for xdg's "high-value and low-difficulty" criteria - I feel like this is just as presumptuous

As I wrote that quickly, let me add that I put it in quotes originally to denote that these things are hard to evaluate. Voting on features is just one form of a statement of "value" -- but that in itself doesn't help prioritizing a volunteer (or thinly resourced) project because it doesn't deal with the resource constraint.

My point about "difficulty" was not to say that volunteers be assigned to things (that won't work), but rather to imply that should someone (TPF) be considering bounties or grants that these be focused on areas with quick, tangible deliverables. This is consistent with principles of agile development -- focusing on frequent delivery of working code.

My idea for pledging money for fixes ("Perlbug Pledges") is just one way of using a real resource like money as a statement of value by "the community". Volunteers willingness to take on certain bugs for the pledged amount of money addresses the difficulty factor and scarcity of resources.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Part of the issue is that there's a huge rampup time. Maybe, p5p should spend some time documenting more. I'd chip in for a bounty on that ...

I can't recall a single good idea accompanied by working code turned away in the past five years I've read the mailing list.

I can. Migrating Win32API::(File|Net|Registry) into the core. Fixing pseudohash lookups so that things like

my $x=[{foo=>[]}];
$x->{foo}=1;
[download]

dont eat up all your ram (darned if i can find the mail that had the patch in it when i search tho). Fixing native Win32 command line handling so globbing is automatic as it would be on VMS and thereby simulating how it works on *nix. Fixing <> so it cant be used to rm -rf /. And thats just with a modest amount of searching, or asking in the CB. I'm sure if I looked hard Id find a bunch more.

I like the idea of votes. I think that certain personalities have historically had their (negative) opinions weighted far more heavily than they should be. A proper voting mechanism would counteract that. IE: "We have 300 people who said that it should work like X, just because PERLGURU thinks otherwise shouldn't outweigh them."

Renaming 'err' to 'dor'... Ummm.... :-)

Do you not like renaming "err" to "dor"? The latter is more accurate as the first implies that an undefined value is always an error, which it most certainly is not.

Cheers,
Ovid

New address of my CGI Course.

Yes exactly. I do like renaming 'err' to be 'dor'. That was the point. See my other posts, or my rants on p5p on the subject. Or read a minor summary in the subthread starting at Re^7: Why Perl 6 is taking so !@#$ long

---
$world=~s/war/peace/g

Every time I see dor I have to think durr…

Makeshifts last the longest.

I can't recall a single good idea accompanied by working code turned away in the past five years

I can. Two of them. Of course, you could argue about whether they were good ideas, and whether the offered code was complete in every detail.

Update: A link. (That was working code built on 5.8.6).

For the latter, there is little point pursuing fully tested and documented code, if the idea itself is reject out of hand.

For the former, I see that both ideas have now been adopted into 5.9.3

I agree, but I also think Anonymous should pick better things to ask for. A perl compiler has not been pursued because it has very little real-world value. I have never had a single problem with perltidy, and I suspect only people writing really questionable code do have problems.

The list of proposed items here is much better.

I have never had a single problem with perltidy, and I suspect only people writing really questionable code do have problems.

On the other hand, if you have a tidy codebase already, you don't really need perltidy to clean it up.

It's when the code is an absolute mess that you need a cleanup tool the most.

Just my $0.02,
--
Ytrew

I didn't mean messy code as in indentation and brace style; I meant code that uses very obscure features of Perl's syntax. The kind of stuff people use in some of the obuscations might be very hard to tidy, but might also be not worth fixing.

I even got one just for starting that wiki page.