FD.o: stepping towards clarity

Waldo wrote an entry in his blog querying:

I also believe that at some point we must be able to say “this is something that is widely adopted and deserves to be a standard”. How should the process for that look like?

well, if we are serious about FD.o being a place of useful cross-pollination and creation of technologies that evolve into standards, we need something that will lead us there. a formalized body like the FSG is a bad fit. since FSG is designed for the consumers of our work (ISVs, vendors and ultimately users) as opposed to those creating it this should be no surprise. what we need is not an application formalization as much as a way to collect and expose the realities of the development process. if we could see who was working on what, who had adopted what, what projects had overlap or relied on each other, etc... we could chart a relatively easy path forward. all this information exists, but it is hidden from our eyes right now.

were i adequately motivated to reorganize FD.o[1] the first thing i'd do is get rid of the wiki for the specifications area. i can't imagine a domain for which a wiki is less suited because making changes to that body of information is going to be an unnecessarily large undertaken as one must edit each page individually. a wiki is great for a collection of data for which no systemic structure to the contents is required, but horrific if there is. instead, i'd replace it with a nice little web app. it wouldn't need to be complex, but here's what it ought to do:

1. allow logins so we have some concept of identity to which to tie ownership. in fact, i'd try and look upon this as a case study for authorship identity management in the free software world.


2. create a standard set of information for each spec/project that must be maintained. each spec/project seems to have pretty well standard information already: description, mailing lists, web sites, references, drafts and releases... codify this structure and allow editing of it via web forms to keep consistency. technology dependencies and related specs/projects ought to be a part of this information.


3. use a simple, bare bones document management system to manage uploading files. this can be unbelievably useful for versioning and making systemic changes to presentation.


4. require that each project/spec has at least one owner and encourage listing of other identities who are involved, probably through an "owner invite, member accept" mechanism.


5. have identities that represent participating projects (e.g. KDE, GNOME, XFCE, X.org, etc)). any project may participate simply by creating an identity, and any of the user accounts can be associated with these project identities. only people from these projects are allowed to note the current state of interest and/or adoption of any given spec or project for that project.

with these bits in place FD.o would then be able to:

• see who is involved in which projects (social networking, here we come ;)
• monitor the activity of projects, allowing questions such as, "which projects have achieved Stable but aren't widely adopted?", "which projects have a high level of interest but low adoption rates?", "which specs are going nowhere fast?", "which specifications have unanimous adoption?" and many more to be answered with a database query
• generate overview reports of current progress and adoption without the need for jockeying and convincing as was seen so often on the xdg platform mailing list
• a simple, fact-based mechanism to say, "this is a de facto standard."
• the ability to change the presentation, layout and reporting easily in the future to grow with evolving requirements

this whole idea is based upon the concept that FD.o is a collaboration zone which ought to be a self-documenting entity. nobody should be able to state "this is a standard because i say so", or the reverse. the usage or interest levels should provide self-documentation. i'd also start by adding in base technologies, such as DCOP, that aren't being developed "within" FD.o but which are of prime interest to it.

to drill a bit deeper into the concept of "usage and interest" levels, a project should be able to mark any entry in the FD.o universe as:

• rejected
• not interested in this time
• unexamined(the default prior to active marking)
• neutral
• interested
• actively participating (== not yet released in a stable release)
• adopted (== used in a stable, meant-for-users release)

the app need not be complex code-wise, but it would be a bit of work. so there's the age old problem of filling that work with wo/manpower. to be honest, i don't see a volunteering jumping up and doing this because it's drudge work and really benefits the non-volunteer members of our community more than anyone else. so it would be nice to see a vested interest step up and fund someone to develop this app. someone like Red Hat, Novell or Intel.

[1] why am i not adequately motivated you ask? it's because i'm already involved in enough other things that i simply don't have more volunteer hours left in me. i'm a limited resource. i'm passionate about FD.o but don't have the insider status required to make these shifts happen and lack the time to develop the cred required for said insider status.