Re: [trinity-devel] Improving the Web Site and Adding Documentation

Do we have access to the old KDE web site pages? The Trinity web site provides no package description pages like the old KDE web site. I think we could use such pages. I'm no HTML expert but if we have an archive of the old kde web site I am willing to help massage the old pages into Trinity pages. Second, I noticed when building the 3.5.13 packages from tarballs that some of the old /usr/doc files were not part of the binary packages. Fair enough, most of that was stale and useless. However, there is a readme file in every package and the file says nothing more than to visit the wiki to learn how to build each package. The wiki is lacking in specific package information. I can update the wiki but I don't know what is relevant. That is, I had to heavily patch a few 3.5.13 packages in Slackware, but I don't know whether that is true for other distros. I had to do some serious head scratching to get some packages to build and having specific information would have helped. Perhaps an improved approach is to create a wiki page for each package with instructions for building. That documentation should be duplicated in the package readme file. Many of the pages will be repetitive because they require nothing different or unique. Or create individual pages only for those packages that require different build options. Certainly any package that requires one or more patches needs that information. Lastly, long ago I mentioned the idea of a Trinity user's guide. Something that allows multiple output options, such as HTML, and PDF. Packagers could add a desktop icon to the generic user profile and first time users would see the icon right away. Several distro maintainers do this and I always liked the idea. The user's guide would be part of the Trinity web site too. I am willing to help. I'm not demanding anything :) --- just trying to start conversations. I welcome that GIT and bug quashing have priority for 3.5.14. I want that to succeed --- especially the bug quashing. :) I think documentation is something that can grow and mature on the side. Do we need a plan?