Hi Stefan, On Tue, Apr 15, 2014 at 01:28:46PM +0200, Stefan Schnyder wrote: > Now my thoughts: > > * I think, that our website doesn't need to contain that much > information. It needs to get people started & provide access to > further information and tools (Daniel had some nice ideas there).
Yes, I agree. > * The current info on the website, the manual, the wiki(s) and all > info out there should be in one place. Preferably a tool which may > be edited over a browser, if we want to give all people the ability > to edit as well. Two thoughts. One is that maybe not absolutely everything must be in one place. Different documents are updated with different frequencies. For example, we have a number of project pages on wikidot used to coordinate collective efforts, for example the mass perl module rebuild. Others such as the manual, are updated less frequently. Perhaps the collective notepad case and the more static notepad case do not have to be accessed with the same mechanism. The second thought is access. For example, I like the checked in manual, because it's simply part of our code base. If you can commit a build recipe, you can commit a documentation change. The amount of friction is a tiny bit higher compared to in-browser editing, but at the same time, it's more inclusive: every maintainer has a text editor and subversion access. You don't have to ask for extra permissions on wikidot, for example. It's easy to test the changes: you edit files in pkg/opencsw-manual/files, type "mgar clean install" and you can view your modified manual online, e.g. for me the URL is: http://buildfarm.opencsw.org/~maciej/opencsw-manual/ If people still think this is hard, I won't have an objection to migrating elsewhere. But for now I want to propose that we stick with a checked-in manual, and not require in-browser editing. > * I support the idea of separating information from bugtracking from > mailing lists from social media, etc. There should be only one place > for the same kind of thing, but a place for each kind of thing. > * The rework should be coupled with the new website that Daniel is > working on. > * It may be worth a thought if we should separate our "product" (the > recipes & packages) from our own tools (gar, buildfarm, ...) or > combine them. I'm talking about info & bugtracking & (...) for each > or for both in one place. Having only one place would/could reduce > the maintenance on the tools, but maybe lead to confusion for the users. We've talked about this for a long time. AFAIR, Dago argued that it's better to keep recipes and corresponding GAR versions in the same repository, because you can check out the repository from a given point in time and they're likely to match: you can check out an old recipe from and old revision, get an old version of GAR and build it successfully. For my own workflow, I keep two separate checkouts, one for the recipes and one for GAR (via git), so they're pretty much already separate for me, and I think would could separate them. I also think that it doesn't matter that much. > I would like to propose, that we decide on a existing or new tool > for storing & presenting information and then gradually start moving > stuff away from the old locations. I would volunteer to do the > moving. > > What are your thoughts? Deciding on documentation formats and places is something we've generally been bad at. If you want to do the work, I say you get to pick the technology. Think about how it will be maintained in the future: the lower maintenance cost, the better. For example, please try to avoid creating a new place where everybody has to create a new username and password. Maciej
signature.asc
Description: Digital signature
