Ok. This is another post that's two thirds philosophical positioning and one third "things you can do". If you'd like to skip to the last third, then follow this link.
Now we've got rid of the people who don't want to listen to me waffle randomly, let's start with the nice, pithy central point that they're now all going to completely miss: The simplest way to get something from somebody is to find a direct means of contact and ask them.
Apparently this is hard though. People much seem to prefer complaining on blogs, assuming the status quo isn't going to change. Well, if you assume that the other person's opinions are both contradictory to yours and immutable, then sure, they're never going to change their mind. Because you'll never try to change it. Worse still, you'll never get the chance to find out if they were actually on the same side as you all along and you just misunderstood each other.
Failure: there was an Iron Man post early on about exceptions where somebody commented complaing that DBIx::Class didn't produce an exception object hierarchy for errors and that on every project he was on he had to waste time recreating one. I followed up as soon as I saw this going "hey! we'd love one of those! have a branch! have as many branches as you need!" or words to that effect but I'm not sure he ever saw it; certainly, no code has resulted that I know of.
Success: The DBIx::Class team had been steadily subclassing SQL::Abstract in nastier and nastier ways because we couldn't get any response from the maintainer, but I refused to fork it because we hadn't heard from him at all. Then he popped up on the Catalyst mailing list working on some Cat+DBIC stuff and I went "hey, I've not seen that From address before" and dropped him a quick mail and the reply was basically "oh my god I left an address that doesn't work on the CPAN module sorry" and now the DBIx::Class team plus assorted other wonderful people like Laurent Dami of DBIx::DataModel fame have banded together and we've released 1.50 and work progresses on the prototype for 2.0.
Then, the other day on IRC, zby commented that "mst seem to maintain that for every critical public post you should consult the matter with the parties involved". Well, I'm not necessarily going to go quite that far, but ... a lot of times I've been brewing up a rant for a while. And then I've had a chance to talk to the person the rant was going to be directed at and hey presto it turns out they'd love that to happen, they just need some help. I've spent a couple hours triaging the easy bits on an RT queue so a maintainer could get a bugfixed release out and solve a DBIx::Class problem. I've found somebody a shell on a system so they can reproduce a problem. I've asked somebody for a shell on their system so I can reproduce a problem.
Four times out of five, the end result is that I've got nothing to be critical of - and better still, over half of those times the end result is me having an exciting "we can fix this and here's how" story to tell, which is the story I'd much rather be telling because that means we're part of the solution, whereas extended complaining without concrete suggestions just makes you part of the precipitate.
So I think, yes, we should try. Any time we can. To quote from the notebooks of Lazarus Long - "Your enemy is never a villain in his own eyes. Keep this in mind; it may offer a way to make him your friend. If not, you can kill him without hate -- and quickly.". Now in our world "kill him without hate" means something more like "move on, understanding why this person disagrees with me" - but the quickly part is extremely important as well, because it means we don't expend time on anger or upset that could be more productively expended actually achieving something. And that's pretty much the worst case outcome of this approach.
Well. Except there's a darker side. Getting good results relies on finding the specific person that knows what's stopping your problem being solved and making a unique, personal approach to them. If lots of people basically send the same email or letter or whatever then it's just going to seem like noise and generate hostility towards the idea. If you aren't willing to compromise then you aren't going to get anywhere. Worst of all, if people get indundated with suggestions, the vast majority of them poor, they can easily start to consider every idea they're sent to be guilty until proven innocent.
This is also why you want to try and avoid repeat bug reports and check the rt.cpan.org queue for a module before reporting the same problem again. It's why you actually have to think about what you're saying, and remember this person has never spoken to you before, has no idea who you are, and no reason at all to accord you automatic respect - so you have to make a start on earning it from that first interaction.
So next time you're about to blow your top over a problem, next time a rant is about to pour forth out of your keyboard and onto the internets, see if you can find somebody who holds a position such that they could influence the outcome. Then think about what you want, and why they might care that such a thing comes to pass or at least that you're given an opportunity to do the work yourself to fix it, and what help you could potentially offer to them. Then, ask.
The perl.org repository and patch aggregation plan
People have been complaining for a long time that the main perl.org website and subdomains like learn.perl.org don't get updated often enough. So I made the mistake of assuming for a while that there wasn't a lot that could be done or, clearly, somebody would have done it already.
WRONG.
After ::NA I thought I'd wave at the perl.org admins and ask if there was any way to get updates in. The reply I got was basically "sure, it's in svn. Sign up here, log in here, check it out and send patches." My jaw nearly hit the floor. So I grabbed somebody who'd been complaining and went HEY LOOK YOU CAN DO SOMETHING and got a "huh? I have to sign up? that's not public" in return. Which is the point at which I realised that the biggest problem is nobody found the repository and/or nobody thought to ask - so I went back and begged them to set up unauthenticated read only svn for people to make patches against.
It's up. Check it out.
svn co https://svn.perl.org/perl.org/docs/live/
Fortunately, the other thing we needed was a way to make sure that people didn't tread on each others' toes - a co-ordination point so that those of us who care can thrash out patches before they go upstream, and to make sure work doesn't get duplicated - and the entirely unofficial perl.org patch marshalling and discussion list will serve that purpose.
So, if you're interested in working on perl.org or learn.perl.org, hop onto the list and we'll tell you when the svn's stable - and hopefully share knowledge of installing and running the Combust system that the sites run atop so that we can test patches more easily.
Because in free software a question in the form of a well thought out patch is one that almost always gets a constructive answer.
Let's make those questions and ask them.
-- mst, out