Web lists-archives.com

Revisiting the TechBase situation (2 proposals)




Greetings,

I won't be going into history but right now we have two developer-facing wikis: TechBase and Community. On paper, the division between the two is clear: "external" vs "community". In addition to still being in transition, the distinction doesn't always work well in practice:

- Tutorials and information for external developers (a.k.a. users of our libraries/software) are pretty much the same tutorials new internal developers would use.
- Readers are led to jump back and forth between the two wikis, which may make them lose context.
- There is also a risk that documentation gets duplicated, put in the wrong wiki, forgotten, etc.

On the non-technical side, it also creates this "them vs us" division. Of course, we do have hard rules on projects that get hosted on our infrastructure as an official part of the KDE community. But putting up that fence there might not be a good way to encourage "users of our libraries" to eventually become part of the community and help develop those libraries.

That said, I am also playing my own devil's advocate here. "TechBase" is admittedly a catchier name than "Community Wiki" and is symmetrical to "UserBase". Searching for tutorials on Google shows more TechBase results due to a longer history, page ranking, and stuff. So if I may, I'd like to propose two somewhat opposing options on how to move forward with these two wikis:

OPTION 1: Sunset TechBase, put everything in Community Wiki

PROS:
- All-inclusive, all-welcoming place for any kind and any level of developer
- Everything is one place, easier to search, easier to see duplicates, no jumping back and forth

CONS:
- Could make the Community Wiki crowded
- Lose search ranking, lose a catchy name


OPTION 2: Redefine TechBase - make it really only about technical stuff: tutorials, architecture/infrastructure, overviews. Remove the "external developers" distinction. This will also be where projects will put their technical docs for contributors.

PROS:
- Keeps the TechBase name (and SEO stuff) without the external vs. internal division
- Better defined purpose. Community Wiki will just be for the "human" side of documentation: planning, minutes, project notes, etc.

CONS:
- Still jumping back and forth between two wikis
- Some technical information have already been migrated to Community Wiki

In addition to some material being outdated or irrelevant, having some in one place but others in another doesn't help give new and current developers clear path. I'd love to hear thoughts on the matter and other options we might have with regards to the wikis.

(Apologies for the rather long email. Please be sure to keep both kde-devel and kde-www in the replies as I'm not subscribed to the latter.)


--
Regards,

Juan Carlos Torres
Jucato