The Maps plugin allows you to create, manage and display Google Maps in your site. The 1.3 version of Maps plugin now supports Google API V3.
This new version of Maps plugin also brings some new features:
Download Maps plugin v 1.3+: http://geeklog.fr/wiki/plugins:maps
The Hello Plugin allows you to write, save and send html emails to groups. As some mail agents don't support HTML or their users prefer to receive plain text messages, Hello plugin include a plain text message as an alternate for these users.
Hello plugin also sends daily digest automaticaly if this function is activated in the main Geeklog config. You can set the number of emails to send per run to avoid server issue. You can also send daily digest when you publish a new article, or you can reset a user's daily digest settings (articles and forum) which will come in handy when the user's email address became invalid and emails start bouncing.
"Was", unfortunately, because PJ has decided that, effective immediately, the site will no longer be operating.
The owner of Lavabit tells us that he's stopped using email and if we knew what he knew, we'd stop too.
There is no way to do Groklaw without email. Therein lies the conundrum. (...) So this is the last Groklaw article. I won't turn on comments. Thank you for all you've done. I will never forget you and our work together. I hope you'll remember me too.
Thanks, PJ and the Groklaw community for all you have done for Open Source in general and Geeklog in particular. We will sure remember you all!
For the rest of us, maybe it's time we think about the recent events and disclosures and what can be done about them, as they seem to start to be doing more harm than good.
Google has just announced the list of students accepted into this year's incarnation of the Google Summer of Code. As you know, Geeklog did not make the cut for GSoC 2013, but the Fedora project generously offered us a student slot under their umbrella.
And so I'd like to announce and congratulate Benjamin Talić as the GSoC student for Geeklog this summer. Benjamin will be working on a project to crowdsource the Geeklog translations, hopefully helping us to keep the 30+ translations of Geeklog's UI into various languages more up to date in the future.
Congrats again, Ben. Welcome to Geeklog and we hope you'll have a great and productive time on the project :)
My least favourite part of the Google Summer of Code (GSoC) is having to turn down all those students who sent in great applications and showed real enthusiasm for their project. But sadly, slots are limited and we have to make decisions.
But then there are also those applications that are ... not so great, to put it mildly. With all the available resources out there, you would think it's easy to read up on how to write a good application. In addition to the extensive GSoC FAQ provided by Google, there's the Student Guide as well as other useful publications, like the free ebook Open Advice, which contains tons of tips from open source mentors and former GSoC Students.
I realise all of this comes a bit late for this year's GSoC, but I thought I'd put it up now, for future reference, while memories of the latest round of application reviews are still fresh. So, in addition to the above-mentioned resources, here are some things that stood out in applications that we received over the years.
Your credentials may matter less than you think. When I read a proposal for the first time, I usually skip the CV section. I'm more interested in your understanding of the project. That doesn't mean that you should leave these things out - I'll get back to them eventually. It's also perfectly okay to be proud of your accomplishments. Just don't assume that they make all the difference. In open source, we're usually more interested in what you do now than what you did in the past. Are you interacting with us? Do you show interest in the project and the community?
I have complete knowledge of MySQL (from an actual application). Really? There are only a few people on this planet who could get away with such a bold statement. So unless you're Monty, you may want to be a bit more humble in your self-assessment.
Be realistic. Don't promise to work 70-80 hours per week on your project. Nobody can keep this up for 3 months and deliver good work. Your GSoC project should be treated like a normal job, which by Western standards means something like 35-40 hours per week. This is also the amount of time we take into account when proposing the project in the first place; if you need twice that amount, you're doing something wrong.
Be realistic, part 2. When we put up a project for students to pick from, we assume that it will take someone who's new to the project about the available time (3 months in GSoC) to complete. Trust us on that - we've been doing this for a while. Things may be more complex than they seem at first. So don't suggest that you could do two of our projects during GSoC. It only tells us that you haven't really looked into the project yet.
The real reason we're asking for a schedule. I'll let you in on a secret: When we ask you for a schedule for your project, we don't believe for a minute that this is how it will work out during the summer. We ask for a schedule to make you sit down and break the project down into smaller parts and to think things through. In doing that, you will often find aspects that you haven't considered before. It's easy to read a project summary and think "Yeah, I can do that". It's another thing to really think about all the necessary steps.
Don't shout. In all forms of communication over the Internet, writing in all caps is considered SHOUTING. Please don't shout at us. In the context of an application, this can also come across as desperation (PICK ME!!1).
Improve your English. I realise that this is a touchy subject. Not everybody is a native speaker (I'm not, btw). We don't expect perfect English. But we do need to be able to understand what you're saying. Some of the work you're going to do will require attention to details. We don't want those details to be lost in translation.
Spelling. In addition to the obvious (use a spell checker), please also pay attention to the correct spelling of names and technologies that you're using in your proposal. It's only a small thing, but it doesn't exactly improve our confidence in your proposal when you misspell things such as the name of our project.
Use your time wisely. There are no bonus points for submitting a proposal early. But if you prepare it early, chances are that your potential mentor will find the time to look it over and make suggestions for improvements before you submit it. They won't have that time near the end of the application period.
Talk to us. This point really can't be stressed enough. From experience, applications that appear in Melange "out of the blue", without prior contact with a mentor or the community, usually aren't very good. Make sure we've seen your name somewhere before - on our mailing lists, the forums, or on IRC. Introduce yourself, indicate your interest in a project, ask for feedback on your proposal, do something useful. GSoC is not only about doing a project, it's also about getting to know new people.
The student participants for GSoC 2013 will be announced on Monday. The above tips will still be valid next year, though (should Google decide to run the program again).
The new version of Media Gallery WKZ plugin is available for download.
It is corresponding to Geeklog2.0.0 now, and some fixes are included.
Download the plugin from my site and have fun!
Google have announced the 177 organisations that are participating in this year's Google Summer of Code (GSoC). Unfortunately, Geeklog didn't make the cut.
However, we are still participating in GSoC 2013 thanks to The Fedora Project, who generously offered us one of their student slots. Thanks, Fedora!
If you are a student interested in working with Geeklog (and Fedora) in the Google Summer of Code 2013, please have a look at the project ideas we selected, which are listed over on the Fedora Project's ideas list.