I was talking to a new freelance writer for LDN this afternoon, and when the subject came up about how I decided what topics to cover.
This is a valid question for most commercial publications, because writers understand that editors have to focus content to a specific audience. What will pique the readers' interests? CNET News or Jupitermedia will not feature too many stories on Linux, for example, because they believe that (rightly or wrongly) not many of their readers will be interested in a lot of Linux stories. There is a common misconception that "mainstream" media sites will avoid topics on the behest of the advertisers. Typically this is not the case: sheer numbers drive the choice of content, which in turn drives the amount and type of advertising sold.
But I found myself in the happy position of being able to tell this writer that since LDN is not a commercial entity, we are not constrained by such parameters. While we certainly welcome all the traffic we can handle, the idea here is not just to inform readers once then move on, but to build something more permanent: a knowledge base. Due to that mission, my selection criteria is far more simple: if it's about developing with or for Linux and it's not redundant information, we want it for LDN.
While my editorial selection process is greatly simplified on LDN, it does present me with the daunting task of trying to organize this growing storehouse of information. When looking for information on classifying documentation around the Linux space, it soon became apparent that there really hasn't been a big effort to create a global classification system for documentation.
This is a big deal for anyone that wants to provide users with an organized way of finding Linux information. Like me. I surfed around to the major distributions' and desktop environments' web sites this week to see how they did it, and it seems everyone uses a different way to organize their knowledge. In the age of Google, this might not seem like such a problem, since a good keyword search can usually dig down to the document a user needs. It is a significant hurdle, however, as more ISVs and defecting Windows developers come into the Linux world and start looking for specs, API documentation, and manuals that will help them figure out how to get started.
Which leaves me in the position of coming up with a classification system for LDN's knowledge base. It will be a system that I hope other sites might adopt, too. A universal classification system would enable developers to quickly find the documents they need. It would also greatly assist project owners to identify gaps in their project's documentation. If Project A has Specs X, Y, and Z, then the owners of Project B might ask themselves why they are missing Spec Y, then fill that gap.
For those of you who might be reading this and thinking "oh, no, not another standard," I don't think such a classification system has to be that rigorous. It just has to have a common set of labels that any project can adapt to fit their needs.
What would such a classification system look like? I'm still pondering that question, because this is a big taxonomy system that needs built. I think at the "kingdom" level there needs to be two groups of documents: descriptive documents (specs, etc.) and implementation documents (manuals, etc.). The rest will be coming as I think about it some more.
But is this indeed needed? Or should I just free tag everything? Constructive input, as always, is welcome!
