On Thu, 4 Aug 2005, Bryce Harrington wrote:
Date: Thu, 4 Aug 2005 11:47:34 -0700 From: Bryce Harrington <bryce@...260...> Reply-To: inkscape-user@lists.sourceforge.net To: inkscape-devel@...6..., inkscape-user@...6... Subject: [Inkscape-user] Proposal for inkscape-testers
Hi all,
In the past few weeks I've attended a *bunch* of talks on open source communities, testing, and so on, and at the same time have noted the growth of the Inkscape community over the past few months, most especially evident from the growth of list traffic with the 0.42 release.
At the same time, I've noticed that the project has been simultaneously gaining some better testing approaches while it has faced some QA challenges, most tangibly evidenced by the need for a 0.42.1 release to correct some errors due (it appears) to insufficient package testing.
About a year ago, we budded off the inkscape-users community, which has proven to be quite effective. The list surpasses inkscape-devel in membership, and has helped foster our user community to get involved in doing things like setting up the deviant-art sites, help with the about screen contest, spread PR, conduct testing, and assist other users.
I would be interested to see how much overlap there is from the developer list. User lists work best when users provide each other with quick rough answers first and then developers can step in to provide additional information where needed.
I've always thought compiling from source was developer territory but it is often brought up on the user mailing lists and if you want to keep it that way then is it essential to have developers on both lists.
Sometimes lists get created to give less attention to things when in fact lists should be created to give them more attention.
Anyway, yesterday I heard a talk about how the Mozilla project similarly divides into sub-communities like we've done with -devel and -user, and
It is worth noting that Mozilla has problems and seems to have inherited a certain amount of Not Invented Here (NIH) from Netscape (I'll spare you the history lesson, start a new thread if you want me to explain). I also think they have had problems identifying their purpose and their target audience ever since the browser stopped being a way to sell Netscape servers.
Far as I can see Inkscape has clear goals of implementing the SVG standard and promoting open standards, as well as creating a fully featured drawing application. Inkscape is complicated by necessity but for that reason doubly committed to usability.
have seen similar benefits (the NYT article organized by the Mozilla marketing community being an excellent case in point). I was particularly interested to learn that one of their most vibrant groups is their testing community, which organizes its focus specifically around making the browser better, collecting useful information from users, and ensuring there is sufficient test coverage of areas under development.
Presumably each community has a clear and specific leader to steer them in the right direction and make sure there is the necessary cross communication with other groups.
I think that given the strength of interest in the Inkscape 0.42 release, and the need for better testing that it's shown, that right now would be an opportune moment to form an "inkscape-tester" community.
The project definitely could benefit strongly from such a community. The purpose of this group could include:
- Package testing. As mentioned above, this was a challenge in the 0.42 release, and we need organized help here.
I think this release was unusually rough because of the longer development time. Perhaps the prerelease cycle needs to tuned a little, and the prerelease needs to be out for a while (like a week) without any reported problems before being retagged and rereleasing the same files as the actual release (and I thought this was roughly what was happening already but was a little more rushed this time around for whatever reasons).
- Usability analysis. On the list recently has been a number of discussions regarding usability and the need for increased critique/analysis. Doing this within a community distinct from the development group may help focus it, and reduce the distraction of the debate that it generates.
Ideally I would like to see a deliberate usability review of some form take place as part of every release cycle. I suppose what should probably try and come up with would a checklist of quick tests any user or developer could step through and do their own heuristic analysis of the usability of Inkscape. For me the easiest point to do any kind of review is right after a release (because it will be easy to get more people using a version of Inkscape which closely matches what is in CVS) but that is my personal preference and may not necessarily the best time. Some level of ongoing analysis will be needed but setting a stage of the developement cycle will help draw attention to it I think.
I understand the desire to seperate out the usability related traffic from the main list but depending on people interested in usability to provide the necessary patches is like depending on translators to put the internationalisation infrastructure in place. Which reminds me to encourage translators to provide feedback on any problems they encounter. Translators often represent users who are not native English speakers but for whatever reason are using Inkscape through English and can identify areas which could be improved and reworded to be clearer and simpler which a native English speaker might dismiss as "easy enough" or "obvious".
Translators are second only to documentation writers when it comes to providing valuable insight and finding problems.
In general, the inkscape-tester group would stay at a higher level then core coding, focusing more on finding and analyzing problems, and helping to show Inkscape will work well for all users.
If enough Developers lurk and occasionally respond to issues on the testing list it could work.
I've also thought a bit about some other communities that may be worth forming, such as a documentation community and perhaps a marketing community. Mozilla has both of these communities and finds them successful.
Mozilla is huge. I wonder how they manage to keep drawing people in and reward their contributions (or if they really do at all). I probably do not say thanks as often as I should but is important to make sure everyone feels like their efforts are important. I would be worried that splitting the lists could disappate some of the energy and enthusiasm.
There definitely is a need to help the various people working on documentation to become better organized and to have their efforts more recognized. If someone would be interested in organizing a documentation community, I think we have enough interest and participation to make it viable.
Documentation is not a finite task but sometimes it is treated as such. So far the Inkscape documentation has been treated as creating tasks specific tutorials and I think that is an excellent way to operate.
Of the three, I feel the inkscape-tester community would be the most valuable to form right now, and would give us the most bang for the buck. I'm willing to put effort into getting it organized and started. Are there people who'd like to see this formed and/or participate in it?
quote bryce: "However, the reason for the proposal is not really to migrate traffic off the main list so much as to increase the focus we can give to testing of inkscape."
If the testing list is successfull it will generate even more traffic. Developers, certainly the core developers will still need to watch the list and so that testers can draw attention to really important things that need to be fixed without delay. (If you find yourself constantlys CC'ing another list to attract developer attention you've failed.) As Bulia has mentioned this is unlikely to save developers (like him) any work but it may still be worth doing if everyone goes into it with realistic expectations.
If the list can be started with a clear purpose and the necessary developer support it will probably work. I agree what Ted said, creating too many lists quickly in close succession might cause problems and overstretch things, and a clear sense of what the lists is supposed to be doing and being able to get developers attentions is essential.
Sincerely
- Alan H.