Following on from recent blog posts, what are the barriers to involvement in the GNOME project? And what can be done about them?
Social
- patches go ignored for too long
- many modules are not maintained at all. Probably there should be some developers of which can just commit patches without maintainer's permission.
- Solution: Appoint co-maintainers. (murrayc)
- too many IRC channels are ghost towns. The list may show a dozen people there but NOBODY SAYS ANYTHING when you say hi or ask a question. Solution: don't go on IRC if you're not going to be there.
Tutorial IRC lessons would be nice if done correctly - maybe even a "Developers Screencast" section which could feature a theora/ogg or flash video, code chunks/samples used in the screencast and some useful links - However a decent screencasting tool would probably help, something able to do the ones used by macslow on his website but obviously nice and easy to use.
Technical
- Getting a working jhbuild is a pain
There is some help available in the wiki: JhbuildDependencies and JhbuildIssues
Maybe we should give a sample jhbuildrc (distro- specific ?) that was certified working by a successful run with JhAutoBuild ?
- Documentation seems poor or outdated (think of developer.gnome.org)
- Almost impossible to find a GDK tutorial!
- Too much material is out of date:
- developer.gnome.org has broken links, and stuff people is not aware it's outdated
- old rubbish in CVS
- deprecated (or problematic) things are not marked as deprecated everywhere and still mentioned e.g. in Platform Overview
- hard to find the correspondence between: Application names as seen in the GUI / command line name of an app / bugzilla module / cvs module
- Perhaps add a link in the about page to Bugzilla?
- There is no schedule for gnome development in the future releases. People don't know which features will be implemented, what they will get in the end and so on.
- Still there is no overview of gnome architecture.
It's there: http://developer.gnome.org/doc/guides/platform-overview/platform-overview.html , but maybe not visible enough
More examples, tutorials and "My first GNOME/GTK app" style codechunks would be appreciated - Had no end of trouble getting GtkTextArea and GLADE to work properly, signals need better documentation.
- Site really needs a revamping as the wiki front page looks amateurish with the boxy theme and dull lacklustre colours.
- Better development tools (Anjuta is very good but shouldn't the GNOME team have their own like QTDesigner etc?) and integration with RAD tools like GLADE.
I don't see the point of this: glade, gazpacho do their work well, there's no point in doing a specific clone just for GNOME purpose -- LuisMenina
Besides, Anjuta 2.0 looks pretty good and have GLADE-3 integrated, and a list of great features (http://anjuta.sourceforge.net/features maybe some kind of 'official support', something like 'Anjuta we love you', can do good for the morale of the troops. Everybody loves to be loved.
- I agree, Anjuta needs more support, and marketing as the official GNOME IDE. I think new developers (especially students) will be more attracted to GNOME if it was recognised as such. Here is an observation: In the Computer Science department where I am studying, We have a lab full of Ubuntu (GNOME) desktops. Anjuta 1.x, Glade, and Kdevelop/designer are installed. Nearly 100% of students use Kdevelop, even though Anjuta (1.x) and Glade are both available. This just goes to show that new developers obviously feel more comfortable using powerful IDE's like Kdevelop/designer, rather than the modular tools that GNOME developers seem to prefer. Anjuta 2.x will hopefully attract more new developers to GNOME.
- I wasn't even aware of gazpacho, so the marketing team needs work, but it doesn't look to hot at the moment and seems very python orientated. If you go to the main GNOME homepage, you cannot even see a link to anjuta by clicking get involved etc. Seems a shame as KDE really push their dev tools. Does anjuta even have full GNOME support behind it? It'd be nice if the development stuff was really consolidated into tutorials, tools (like Anjuuta :P), APIs, forums, snippets/samples etc - maybe move it all over to live finally?
- Yes, looks like KDE people care very much about tools, and I think that empowering people is a great marketing strategy.
MonoDevelop does also a good job on being a RAD IDE which has a Gtk GUI designer called Stetic. -- AndresGAragoneses
- Better development tools (Anjuta is very good but shouldn't the GNOME team have their own like QTDesigner etc?) and integration with RAD tools like GLADE.
- What about more support for GTKmm? That 'We Love You, GTKmm!' thing. So, why C++? Why not pure C? Why not python or something more high level? About C, well, don't throw the stones at me ("Be excelent to each other!" ), GTK+ in C is very cool, the bindings, etc, but program apps in C... I know most of you do this without problems, but... it hurts beginners! I can not convince non-free software developers to write a app in C. And about Python... hmmm, how could I say, most people I know have this fetish in binary code. Most developers around here think that bytecode is not a 'real thing', and you become a man only when you make a binary executable program. And OO is the way to go, so binary + OO = C++. Yes, its silly, but beginners think silly things. And GTKmm and C++ are great tools, and if beginners see some attractive starting point, there's no problem in choosing that tools in a silly manner. One day they will know how to choose the right tool for the job, the problem now is attract them to GNOME development.
- Out of interest, now that developer.gnome.org has been deprecated, is live.gnome.org going to get a bit more organised? It's all very well and good to be cool and collaborative, but things seem to have taken a turn for the worse in terms of actually trying to work out where GNOME is going (my impression, anyway).
- Having gtk+ depend on an old automake version is a pain. It should support the latest.
Autohell is hell, I mean, AutoTools should be deprecated by CMake.
