2010/11/26 Simon Wilkinson <[email protected]>: > > > AFSLore Wiki was probably started with that idea but, frankly, it > looks broken and inspires little confidence. There is also problem of > repetition, with so many places to store relevant information, we risk > them falling out of sync with each other. > > We recently switched from TWiki to ikiwiki for the AFSLore content. Whilst > the content was all moved over, little has been done in terms of skinning > that content. I suspect that it is this triumph of content over presentation > that makes you feel that it looks broken. The huge advantage of ikiwiki is > that we can maintain it using the same tools as we use for our source and > documentation repositories.
Out of curiosity, what happens to local changes? > We have a very small number of people looking after our infrastructure, and > their time is pulled in many different directions. This means that > simplicity, and reuse of existing tools, are both huge advantages for us. This sounds like an incentive to integrate all of the tools and content into one system. > Obviously, if there is an offer if ongoing maintenance then that shifts the > balance a little, but we do need to make sure that the site can survive the > disappearance of any one person. That is a good point. > In my view, what we really need for the website is a new design - both > visual, and in terms of the information architecture. The choice of > implementation technology should come second to this. Agreed. I believe we should start with a slightly different question, though: whether we want the site to be a read-only broadcast medium or do we want user interaction. > S. Jakub. _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
