On Mar 10, 2010, at 10:07 , Andreas Jellinghaus wrote: > to me your emails read like you want to remove/loose/strip down > most information. the result might be small and up-to-date, but > it is not acceptable from my point of view to loose all the > information in the wikis we have already. A wiki should have self-organizing capabilites to only show relevant information in a useful way and so that it could be easily found. There can be (and usually is) a lot of "existing but abandoned" information.
The goal would be to get people to relevant information in a few clicks and with minimal scrolling and minimal head scratching "is this what i need, where should i look?" > some more thought on other issues: > please don't move everything to the opensc wiki. instead > let us setup a new trac/wiki to put things there. Looking at the trac contents of engine_pkcs11 and libp11 - seems to be mostly a copypaste. Yet Another Trac Instance won't make it better. It should be a well known software myth: "or devs have the latest tools, the greatest utilities, fastest machines => they should be kickass" when in fact the kickass tools are not used. I don't believe that a new trac instance (or a bugzilla) would make anything better. Buying all the different dieting pills (or yet another food additive) will not help if you don't work with your existing body (opensc trac) > reason: in case we need to create another 0.11.* release, > it would be best to use the scripts to download the wiki > information as is, not a new mix of opensc and other > projects documentation. OpenSC wiki is overloaded with information that has nothing to do with OpenSC. Having more of it can not hurt, especially if it is up to date and relevant. The wiki is not attached to a version. It is live documentation. There is no connection between wiki content and a snapshot of it in a versioned software tarball, doing it with this understanding would be wrong. IIRC the reason to bundle wiki docs in the tarball was that there are users without live internet connection. Whatever gets in the "offline wiki dump" for these people is better than nothing. > same with the bug tracker: if you want a common shared one, > please use a new one. but after this discussion, I don't see > why we want to keep using one at all, if it failed. opensc trac has tickets (from the time it was an open trac, which means this is the way people work in real life. Tickets are old but the point is still valid) about software pieces that do not belong to the "opensc project" (can be fixed inside opensc-x.y.z.tar.gz). The goal is to actually track tickets, not to have a a gazillion of bug tracking software instances. Whatever tool that works is better than nothing or better than a bunch of tools not being used. OpenSC trac has a lot of tickets that represent *something* > I saw you already changed some stuff in opensc wiki, Why? Wiki is for changing. > can you revert that (components etc.)? Why? > and the new wiki notification: > thanks for installing the plugin, but it doesn't work for me - > I always get told I need to set my prferences first, even after > I did that already. You don't have to use it. Maybe I missed a configuration option? It seems to work for me. I'll investigate. > >> Move wiki content from other wikis to www.opensc-project.org/opensc/wiki >> (in a structured way) > > same with other projects, please don't move anything away, unless we have a > new release that does not depend on the wiki for documentation. "move" > is the wrong approach, better is to copy it - either into the source as > documentation or in the new wiki - no reason to delete it in the old wiki. Move was the wrong word. I meant copy. >> After steps 1 and 2 are done, turn on read only mode > > we could make everything read-only right away from my point of view. > why the delay? You are right. >> It seems that you had the impression of "trac is hard, it means a lot of >> spam" understanding. Which is not true > > well, the new spam filter seems to work fine. the old setup without it > had a lot more situations where we were spammed. still I'd prefer a software > with user registration/email verification these days (yes, even though I'm > a happy and active user of mailinator.com - we also have b...@opensc- > project.org so people can send bug requests without subscribing to the > mailing list or registering someplace). Where does b...@opensc-project.org go? How many e-mails has it received? -- Martin Paljak http://martin.paljak.pri.ee +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
