Hello,
On Mar 9, 2010, at 23:28 , Ludovic Rousseau wrote:
> 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?
There have been posts to both lists that are a bit off - like do you "use"
libp11 or engine_pkcs11 or do you "use (developer)" it? As there's a variety of
sub-projects that refer to the same mailing lists, how do you (a potential new
visitor) know which one should you use? Maybe a more clear "for this project
use this list" message would do good. Then again, it would probably draw the
balance towards one list and that would not be good for the other list(s). So
maybe would be better to have a single one.
I also follow very closely OpenID camp and there's a slight similarity between
OpenID and OpenSC in terms of support infrastructure. The theme of OpenID
foundation is "a mailing list (and a wiki?) for all sub-efforts and working
groups". End result? Dead or near-dead mailing lists with most of the
discussion happening on general@ (and some life on specs@ as well).
>From the appointed CEO and lawyer point of view this is nice, all the
>departments and all the separate paperwork and whatnot, but this is not how
>people (who are not paid by the corporate members to work on OpenID) work
>(BTW, do you know how many pages long the OpenID intellectual property policy
>is?* )
Assuming that a real user only subscribes to the list for the duration of his
problems (and then "upgrades" to -devel if he/she wants to keep track of the
status of the project(s)) it would not hurt much either, if they get a glimpse
of the development related mailings, assuming there's a bigger chance that a
useful reply to his problem arrives faster because there are more eyes on the
problem.
Just an idea.
>> - 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?
OpenSC user questions ("stuff you can type to the terminal or stuff you can
reach by clicking buttons in a GUI") should indeed go to the user list. "My
card is not supported" should be a FAQ item with a detailed "what to do when
your card is not supported" tutorial. Yes, there's a volunteer (me) but keeping
it in the wiki should let "ordinary people" help themselves.
>> - 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.
ACK.
>> - 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.
It is required for a bunch of USB tokens with non-standard interfaces. I think
this can be written down more clearly, not hidden. One attitude what I've
noticed is "I have OpenSC and OpenCT installed, because they come from the same
site and OpenSC is the open source card software and OpenCT is the open source
reader software" (And sometimes an additional "Can i use OpenSSH now, after
I've installed all other related Open* software?" :))
>From technical point of view, supporting just a single reader subsystem on
>runtime would IMHO be the best option (and libopensc-openct/libopensc-ctapi
>for those who need it, would make it very clear).
OpenCT only matters on Linux for a small subset of devices, CT-API can
hopefully be announced dead in near future (if not already now). Does anyone
know a decent and recent application that *requires* CT-API?
Note to self: to save disk space, ct-api can be disabled on mac os x.
* OIDF IPR is 7 pages long.
cheers,
--
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
