> 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? I tend to agree, and yes we do need a plan. Why don't you add this as a topic for the Nov. 15 meeting on the Etherpad at http://trinity.etherpad.trinitydesktop.org/15 Tim