Congrats everybody to 2.24.0! Been hard work sometimes, but always fun.
Now while you, dear user, are probably going to send zmrzlina, chocolate, cheese and kisses to your beloved favorite hackers*, you might also consider becoming involved. Here’s some offers I have in mind (unfortunately all unpaid positions). ;-) Not all of them require coding skills (I don’t code either, so “Why don’t you do it yourself?” comments are unrequired).
- nautilus-actions is looking for a new maintainer, see the announcement. Interested in helping out? Or even fixing the most favourite bug? Feel free to contact the former maintainer if interested!
- Update ancient project websites. We have lots of old projects sites in http://www.gnome.org/projects/. You don’t want to code but you know about HTML and a bit of CSS and your Wnglish is good. A list was provided by element3260 as part of his GHOP work, available here – this should be transfered to a wikipage at live.gnome.org first, see the Gnome Goals pages for an example how this could look like.
- Push the Gnome Goals to clean up our stack for 3.0 by providing patches. There’s still enough to do. Also see GioPort and GtkPrintPort.
- Take a look at bugs in Bugzilla with gnome-love keyword set. They are a good place to start working on the code of your favourite project.
- Unrelated to this, worst translation issues will become blocker bugs for GNOME 2.26 too. Providing good applications definitely also includes a well-localized UI, and this is impossible when not fixing them.
Some examples (not to blame developers, but to get a feeling what this means): Missing context, split sentences, english structures, broken plurals.
Most (not all) translation issues are easy to fix and gnome-love bugs too. Just take a look at bugs with L10N keyword set. - Identify unmaintained modules. I’d love to have a small script that could run on my svn checkout and printing the date of the last svn commit (svn log –limit 1) that was not an updated .po file. But I don’t do code, so if anybody has too much time… *cough* Would make it easier to identify rotten modules in order to remove them from Bugzilla and the translation statistics, so nobody wastes time anymore on them.Another shameless request – I’d also love to have information on the language team pages about the date of their last commit for that language. Would make identifying non-active teams or maintainers easier.
- Nothing in that list for you? Don’t want to code? For more ideas, visit JoinGnome.
(* “hackers” refers to developers, translators, artists, marketing folks, bugsquadders, doc writers, …)
GtkPrintPort link is wrong.
Great post Andre! This is a great opportunity for new contributors to get involved.
As bjkail says the link to GtkPrintPort is wrong. But looking at http://live.gnome.org/GtkPrintPort however I notice that the method used will not catch libgnomeprint usage in python apps. Look here for an example http://svn.gnome.org/viewvc/gnome-games/trunk/gnome-sudoku/src/lib/printing.py?view=markup (I promise it will be using GtkPrint for 2.26)
Andre, you can run something as for i in ~/svn/gnome/*; do echo “$i: `svn log $i –limit 1 | cut –delimiter=’|’ -s -f 3`”; done and then you can run sort on it’s output to get stalled modules.
For translations, it’s a little more challenging, but if you don’t mind inefficiency, you can try to get all PO files for locale (`find . -name sr.po`) and then run svn log to get last commit date.
Great post!
Ah.. forget it :) This is not what you were asking for. I will try again tomorrow :)
A redesign of the Rhtyhmbox website is already in progress. :)
I could have a go at making a wikipage of element3260’s document…
@Mats: Just do it and add the URL here once you’re done. :)
@aklapper: I have migrated the document, sorted the layout, and refined some of the content for consistency. It’s at http://live.gnome.org/ModuleMaintenanceWorkspaces/ProjectWebsiteStatus