blogs.perl.org needs your help!
As many of you have noticed and commented on, blogs.perl.org needs help and we're hoping this post might inspire some of you to volunteer time or creative suggestions.
Specifically, the blogging platform we're on has proved hard to maintain and while Dave Cross, Aaron Crane, SixApart and others have done great work on it, the tuits have run out.
You could check out the github repository, or perhaps offer help/suggestions on migrating to another blogging platform without losing information. Specific areas of attention that could use some help:
- Prev/Next links on all blogs are needed (including on the front page)
- Images are broken
- Bring back the syntax highlighting
You can read through the full list of issues to get an idea of some things to take a look at.
SixApart, Dave and Aaron have done great work here and while it started out promising, it's still missing key features to make it a suitable replacement for the defunct use.perl.org.
We'll be watching responses to this, so feel free to chime in. Let's make this a blog that people can be proud of.
Freelance Perl/Testing/Agile consultant and trainer. See http://www.allaroundtheworld.fr/ for our services. If you have a problem with Perl, we will solve it for you.
And don't forget to buy my book! http://www.amazon.com/Beginning-Perl-Curtis-Poe/dp/1118013840/
Running out of tuits myself :( I find blogs.perl.org still usable, except for the comment spam. That needs to be on the top 10 list.
Are their any stipulations like "It must be Perl" or something like that? Otherwise, if MT is giving you fits you could move to Wordpress or something like that.
It seems like many of the items on the list are general purpose items not specific to blogs.perl.org and that it could be beneficial to have patches rolled into MT "Community" (Dev/GPL).
Has there been any thought of moving to MT Dev or even a temporary MT "Multi-User" Dev fork if the issues are related to multi-user installs? Theoretically, having more people use the same software would encourage patches as they are also fixing it for themselves. Other blogging software have had temporary multi-user forks that were eventually merged back in so it has been done before.
Also, is use.perl.org running the latest version of Slash? Could an upgrade be an option?
Personally, I would prefer a forum over a blog. I find them much easier to work with.
Would there be any gain in switching to Melody?
If we consider forking MT wouldn't it be more valuable to move to Melody instead? It would be a great way to support that project and possibly invite additional help with blogs.perl.org
It may just put us in a similar boat with a different color sail but may be worth investigating further.
Aside from that I wouldn't mind seeing more forum-like features to accomodate interaction between users.
Encouraged to see this post. I've posted a number of longer posts recently, and have found working with the markup frustrating. I've taken to writing stuff offline as HTML, proofing locally, and then when I'm done I create a draft on blogs.perl.org and dick around with it until it looks vaguely ok.
I find wordpress much easier to write in.
To address some of the points raised here:
@stevenharyanto: I haven't noticed much comment spam myself. It's the blog spam that I have to clean up regularly.
@Robert: I don't think it needs to be Perl. But I can imagine the screams of anguish if it isn't. It's tempting to move it all to WP, but even that would be a huge job with the number of users that we have.
@johnwang: I think that the point is that MT is a pretty grim codebase to work with. The number of people prepared to dive in and look at it is small. And shrinking. use.perl isn't running any version of Slashcode right now. It's a static site.
@shawnhcorey: If you want to build a Perl forum site, then please feel free. This is a blog site so we'll be running it on a blog engine.
@Luis: The only benefit that I can see in moving to Melody is that the Melody team might be keen to take the site on to use it as a demonstration of the power and flexibility of Melody. As far as I can see, it's still largely MT code and the caveats above still apply. The rest of the suggestions you make are all great. Are you volunteering to help?
It would probably be worth putting a little explanation of how to work on it's development along with the repo. A quick look at the project suggests it's only got templates, so presumably you need to setup a companion Moveable Type system to use them with to test the changes. The README suggests a professional edition is being used which raises the question can anyone easily test these templates?
@colinnewell -- strange you should mention that, I have this week started on exactly that task.
My main goal is an Amazon EC2 image of the site, which can be cloned, along with documenting the build process so others can replicate their own local dev instance of BPO in non Amazon environs and hack away on that.
Right now I've got a vmware guest that is running the site - AND some notes on the build.
Aside from creating an EC2 image out of that and cleaning up & publishing my bulid notes -- which I will be doing -- the main outstanding question is the DB.
Do we try and "clean" the DB, removing all personal details & make that available? Gets you a closer clone of the site to work on rather than a bunch of dummy test posts/blogs.
But the risk is that we miss some data that should have been cleaned. I reckon it's worth the effort, but ymmv ;)
ps. it's already shaken out a couple of bugs.
pps. Gimme a week or so and I'll be posting on BPO about this some more.