2010/3/9 Martin Paljak <mar...@paljak.pri.ee>: > Hello. Hi Martin,
> Here are some plans that should make opensc-project.org more attractive to > both users and developers and also ease the administration burden. Lets > collect feedback for a week: please let me know which you feel would be > useful or what would absolutely resist. > > - Consolidate opensc-user and opensc-devel to maximize chances of response > and reduce confusion. Many questions that appear on opensc-user should either > have a FAQ entry (read below about faq) or are actually issues that will > require developer attention. Having a single opensc-devel would bring the > list of relevant mailing lists down to two (opensc-devel and muscle, many > people cross-post to both lists even now) Implementation tactics could be > directing people to opensc-devel only and asking existing subscribers > re-subscribe or do it automatically with an informational e-mail to > subscribers. Looking at subscriber lists reveals that about 1/3 of > subscribers on both lists follow the other list as well already. I don't think -devel and -user lists have the same readers. Many users have nothing to do on the -devel list. But most if not all the developers should follow the -user list. I am not sure I understand "Looking at subscriber lists reveals that about 1/3 of subscribers on both lists follow the other list as well already.". What is the "other list"? Muscle list? > - Have a clear path of communication: faq -> mailing list -> trac tickets. > With a single mailing list there is no question where to post and with a > single trac instance there is no question where to file bugs. Hopefully this > will re-animate trac tickets as a functioning issue tracking platform that > would benefit all parties. User's questions should go to -user. A FAQ is a good idea but must be maintained. Do we have a volunteer? > - Consolidate trac instances into a) a single OpenSC trac, moving all wiki > content and closing other trac-s b) closing all ticket sections in favor of > opensc trac but keep the wiki pages (and SVN browser) in read only mode. > Reason for this: Information is scattered between several trac-s, which all > require administration and housekeeping and is confusing to users as well. > None of the smaller trac-s have been actively used for ticket tracking or > have any other changes for months. This could be approached on a case-by-case > basis as well. No change in SVN repos. No objections. For example you can completely close the "GTK Card" project trac. > - Remove outdated static html content on opensc-project.org and replace > with/forward to the wiki. The fact that trac has been not used lately is due > to the registration being closed for a long period because of spam. Open > access to wiki and documentation (with a review for spam and such, of course) > will hopefully improve it. Fighting for spam is easy (or at least simpler) > now that necessary plugins are installed, but I installed them only to opensc > trac. > > Most importantly, I would like to add a "this is what you should do" style > to the current "these are your options, try to figure it out yourself" > approach (so that people would not install *everything* they see on > opensc-project.org and then start to figure out what and why does not work > together.) This is a bit complicated as it is not easy to even suggest a card > with a reliable vendor and good support these days, as pointed out by > François Pérou. But something that should be done. Exactly. Maybe we should "hide" some projects to not confuse users. OpenCT should not be installed in many cases. Bye -- Dr. Ludovic Rousseau _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
