This page is about the convertion of in a gateway to all the developer related subsites, targeted at either GNOME contributors or independent software developers and vendors (ISD/ISV).

Currently is unmaintained and outdated. Its function is being partially covered by dgo needs to be fully migrated and unplugged. GnomeWeb/Library ( is being developed, and this subsite will assume some other dgo responsibilities. Still, a "Development" link is planned in the General bar common to all the GNOME subsites (see GnomeWeb/Navigation). dgo will be purely a gateway, probably with almost no content by itself.

This affects GnomeWeb/Library.


  1. Introduce and link to the development subsites in a comprehensible way.
  2. Make sure valid dgo content is not lost during the process.
  3. No URL loss: old URLs point to the new ones.

Related GnomeWeb/UseCases:

Since DGO is a gateway most if not all the use cases are only vehiculated, they get solved in another subsite. We need to provide clear hints to these users so they know where to go next. Also, we need to refine which use cases will be mostly solved in wgo and therefore can be taken out of the current list.

  • Audience includes users:
    1. I want to learn as much as possible about application X / GNOME
    2. I want to understand the pieces that form GNOME
    3. I want to follow the development of GNOME / of application X
    4. I want to suggest an improvement / report a bug
    5. I want to contribute code / texts / translations / design / testing / marketing...
  • ISDs/ISVs
    1. Where is the documentation for developers
    2. We want to use library X, where is all the documentation
    3. How this platform compares to other development platforms
    4. We work usually with [programming language X], is it supported?
    5. Best practices, known issues & common mistakes

    6. Overview of the GNOME architecture and development platform
    7. What are the licenses, terms & conditions

    8. What is the relation between GNOME and GTK+
    9. Do you have a roadmap / long term plans for your development platform?
    10. What are the compatibility issues we should consider
    11. At which extent (backward) compatibility is assured.
    12. We want to submit a patch
  • Public sector
    1. We want to know about deployments howto's, institutional reports and recommendations
    2. How to work together
    3. How GNOME is dealing with standards, local languages, accessibility [and other features required in public developments]
    4. How to provide quality feedback based on our GNOME experience
    5. Is it any kind of certification we could require when hiring GNOME administrators
  • Contributors
    1. I want to get a CVS account
    2. I want my project to be part of the official release


This is a proposal.

  1. Agree on a plan at gnome-web-list (ongoing)

  2. Announce this goal to all the projects with content at dgo.
  3. Fix a calendar for unpublishing the current dgo content.
  4. Update explaining the current situation and keeping only relevant links to secondary pages.

  5. robots.txt telling search engines not to index dgo pages
  6. All dgo pages with a header explaining the situation and linking to more information.
  7. Prepare the new dgo page(s)
  8. Make sure all relevant content has been migrated
  9. Set the appropriate redirects to new pages
  10. Make the change once the rest of subsites are ready
  11. Reopen the subsite to search engines and release.


To be defined. By default it's only one page, perhaps more if we find good reasons. It will depend on the use cases and the information for developers available at wgo. See also this draft.


Not available yet. Probably based on GnomeWeb/LooknFeel


Just starting to draw ideas here.

GnomeWeb/Navigation defines the subsites to be linked:

Since wgo will have basic information related to development, we need to link to the appropriate wgo pages as well. This will be helpful to newcomers falling in the dgo page by accident and finding the links to developer subsites too tough.

It would make sense to have a Get Involved promo pointing to wgo/GetInvolved or a more specific page. See this old bug.

Current Content Analysis


Completely outdated content. Last news entry is from 2004. I guess we don't need it anymore.

Release Planning

Links to ReleasePlanning. So, it's migrated.

GNOME Developer's Feature Article

The latest feature article is "Getting the Most Out of GNOME CVS". So, you can have an idea of how outdated this is. There are 7 feature articles in the archive. Move them to wiki or make them available on library.g.o?


Most of the content of those pages overlap with the Overview of the GNOME Platform written by Shaun. Also, it's quite outdated. Making Shaun's guide available in library.g.o should be enough.


This one has several subsections.

"GNOME Policies" only have the accounts policy which is in NewAccounts.

"Whitepapers" has three items: one article about Nautilus internals (which could be available in the wiki or library.g.o) and two (useless) links to libxml and libxslt respectively.

"Tutorials" is just a bunch of links to several tutoriais. This could be be simply moved to a wiki page. "Programming Guides" has a list of guides which could be available in library.g.o. Some of the articles are obsolete.

"API" is a list of links to API docs for GNOME platform libraries. This could be available in library.g.o.

"Standards" is a just a list of specs. Most of them are part of FreeDesktop.Org initiative now. No need to have it.

"FAQ" links to an incomplete/broken document. No need to have it.

"GTK+/Gnome Application Development" links to a webpage about Havoc's book. A link to the book could be added to some wiki page.

"Online Books" links to Havoc's book and another book called "Writing GNOME Applications" by John R. Sheets. Same applies here.

Development tools

"GNOME Bug Tracker" links to some basic links for bug triagers. This content is covered in the Bugsquad wikipages already. "Glade Builder" has links to glade page. "GNU Build Tools" has some basic links about autotools. "Scripts" is a list of small tools for daily tasks for developers. This could be in a wiki page too. "GNOME SVN" is updated but it could be in a wikipage as well. "Getting Involved" is quite incomplete and we already have something better in JoinGnome. "External Resources" is quite useless: just a bunch of links. "Projects" is a list to the webpages of our internal projects. We already have a good and more complete list of them in TeamWorkspaces.


Some important guides from those projects are still hosted in d.g.o. Move them to library.g.o?

Docs to be rescued

List URLs of documents at dgo that are updated and/or important and shouldn't be lost after the dgo disconnection.

See also and


We need to review the dgo related bugs to make sure they are solved elsewhere and close them.


The comments about have been moved to GnomeWeb/Library

  • Assuming that we get working (not a certainty), which can present up-to-date user, developer, and admin documentation (both reference and high-level), and that d.g.o/project/ pages are moved to, what should be left in There is content there that isn't in docbook form, but we could either turn that into docbook (for, or turn it into wiki pages (for -- MurrayCumming

  • The whole point of the "kill dgo" plan was to shift all documentation to -- including stuff that may not already be in Docbook or fit into the requirements of a documentation portal yet -- and everything else to the wiki (which may be called, or, point being it's the wiki we have give or take some redirects). Do not be concerned with "URL loss", that's the wrong way to look at it: We can redirect everything we destroy. Killing depends on

    • I just wanted to estate that "old URLs point to the new ones", which is the same that saying "redirect everything we destroy". Agreed. -- QuimGil

  • could be a place to point developers to the right direction. It should provide links to every usefull location for developers. This include the API docs (, the language bindings (gtkmm, pygtk, mono, etc), the Roadmap and release schedules, the tools a newcomer could use (docs for CVS/SVN, autotools, glade, gedit, anjuta, etc) and other resources where useful stuff could be found (,, IRC, ML). Everything should be included in some documentation what all this is and what it is used for. Some of the tutorials and books for development should stay on the page if they are still up-to-date). -- JohannesSchmid

  • It's been requested that have a section for developers, both of GNOME itself and creating third-party gnome apps (see GnomeWeb/NewWgoStructure). Given that, and library.g.o which will hold all documentation and tutorials, what else is needed for developers? In other words, what would go on dgo? -- joachim

  • I think it could be important to properly differentiate sections for people who develop GNOME, and people who develop apps for GNOME. The current dgo makes no such effort (fist paragraph "[dgo is for] developing GNOME, and applications for GNOME"). It would seem important to orient visitors to appropriate sections, even if this information can overlap. KarderIo

GnomeWeb/ (last edited 2010-03-28 13:04:18 by TobiasMueller)