If you are interested in coding for GNOME, but haven’t figured out what to work on, this post is for you.
In my last post, I described an experiment that I’m running for the GNOME 3.14 development cycle. The goal is to make it easier of people to contribute to GNOME, by making it easy to find tasks to work on and getting rapid and effective feedback.
Since I wrote that post, I’ve been working with a number of GNOME application maintainers to get their bugs in a state where it is easy for people to contribute. The result is three apps that have a clear set of bugs that contributors can get to work on today.
Music
The Music app has been around for a couple of cycles now. It is currently fairly basic, but manages playback fairly well and gives a really nice view of your music collection. This cycle some big new features are planned, like new and improved search and Last.fm integration.
Music has a great development team around it, and is written in Python.
As of today, there are 32 bugs that are available for contributors. Every one of these is in a state where you can get to work on them, and they have all been reviewed by Vadim (the Music maintainer) and myself – so you can be sure that they are things we want.
Some of the bugs are small and address UI niggles, like bug 723144: which aims to give the Artists view a consistent visual style to other sidebars in GNOME. Other bugs are for bigger features, like allowing you to view and play music stored in ownCloud instances. There’s plenty to choose from, and there should be a bug to suit your tastes.
Music is a really promising app, and there are opportunities to play a serious role as it matures.
Documents
Documents is one of the original GNOME 3 applications. It has come a long way, and has a lot of cool functionality. I’m not sure that people have made the most of this app in the past, but I think that its utility will become much more obvious with a few changes we have planned, particularly when managing document collections.
Debarshi Ray is currently leading the Documents effort. He’s a great guy and an active maintainer. The application is written in JavaScript.
There are 43 available bugs for Documents. They include functional enhancements that will make the application much more useful. Adding the ability to sort documents in different ways is one of these. Another is making the list view more usable.
We also have some nice UI polish planned, such as using a popover for search options and having a smoother full screen mode.
Contacts
Contacts is one of the older GNOME 3 apps. It is written in Vala, and is maintained by Erick Pérez Castellanos, who is awesome.
This is a nice app that can really shine with a bit of work. Right now there are 60 bugs that are available for contributors. Again, there’s lots of small UI issues: in the spirit of Every Detail Matters, these fixes would make a big difference to the overall user experience. For example:
- Bug 696384 – porting the contact linking suggestion box to GtkActionBar.
- Bug 699319 – making the app look better when you don’t have any contacts.
- Bug 703201 – allowing users to select contacts using the right mouse button.
There are also some fun bugs that will hopefully make Contacts a bit more engaging, such as showing maps and status messages from contacts.
What Next
If you want to get involved in GNOME, these applications, and the lists of bugs I’ve pointed to, are the best place to start. The nice thing about these apps is that small fixes will go a really long way, and they all have active maintainers. It would be fantastic if people could help us to make them shine for 3.14.
If other application maintainers want to get involved in this initiative, just get in touch or follow the procedure I described in my last post.
great post aday! I’ll keep this link handy if anyone should come around IRC asking for a place to go to if they want to start contributing. :)
Music needs to implement importing, like banshee does for example.
Thanks for the efforts.
Yep, that’s covered: https://bugzilla.gnome.org/show_bug.cgi?id=708933 :)
Personally, for import/export from/te device, I prefer to have a combo-box for switch from “My Music” to “Device” like in this mockup: http://gitorious.org/gnome-design/gnome-design/blobs/raw/master/mockups/music/alt/music-aday.png
This combo-box can serve to switch between differets sources of musics like “My Music”, LastFM, “Jamendo”, “Music shared by computer AAAA”, etc.
We really ought to have a standard, application-independent way of storing music metadata. At the moment I’m loath to try another music player because I’ll lose data.
But Allan, tell us about Nautilus!
Ha ha! Well there’s a bunch of bugs waiting to be fixed: https://bugzilla.gnome.org/buglist.cgi?status_whiteboard_type=allwordssubstr;query_format=advanced;status_whiteboard=nautilus-next;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO
And I’m hoping that the approach I’m trailing here could be used to accelerate Nautilus development…
When talking about bugs… I think GNOME Bugzilla should distinguish between bugs and enhancements. Because my impression is that Bugzilla is loaded with enhancements requests and developers then don’t see the actual bug reports. Separating these two categories properly would allow them to find relevant reports better (and also it would spare us some duplicate reports). In my view, bugs are always more important than new features and should be addressed with preference. Unfortunately that’s not always the case and I hope a better separation would help. That would mean: a) allowing the list view to filter bugs/enhancements b) allowing a reporter to select a report type.
At my company we use Bugzilla milestone based reports a lot to get an idea of what bugs are planned for what release, their severity, status, etc. Not sure if you guys use them? I’ve made up a few examples.
(Sorry for the walls of text).
Ex1. Bug severity / milestone.
https://bugzilla.gnome.org/report.cgi?x_axis_field=bug_severity&y_axis_field=product&z_axis_field=target_milestone&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&product=gnome-contacts&product=gnome-documents&product=gnome-music&longdesc_type=allwordssubstr&longdesc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0=
Ex2. Bug status / milestone.
https://bugzilla.gnome.org/report.cgi?x_axis_field=bug_status&y_axis_field=product&z_axis_field=target_milestone&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&product=gnome-contacts&product=gnome-documents&product=gnome-music&longdesc_type=allwordssubstr&longdesc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0=
Some modules do…
When I was discussing this plan originally, I was interested in flagging bugs that are “roadmap” items: that is, bugs that are a priority for the direction of the module (as opposed to severe issues that are priorities for quality/release readiness). It seems like this would be useful for new contributors as an indication of where the module is going, and how they can participate in helping to move the module forward. This could also be a useful way to have a discussion about what should be on the roadmap.
In the end I didn’t get a clear answer on that. Target milestones or the priority field were both possibilities, though.
Contacts needs to be able to filter contacts when using ie. gmail, so only “my contacts” are show, and not every single entry gmail knows about (which can be a lot as it keeps about every email addy it has ever seen ).
I’m loving what are you doing here. Really hope it will be a success bringing bux fixes, new contributors and better applications. Everything is just amazing. I’ll try to help with my skills. Well done allan!!!