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.
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 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.
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.
* 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.
* Automated testing. Several people have been working on establishing automated ways of testing (including nightly builds and packages), so this community would give these efforts a home.
* Platform compatibility. Inkscape is being used on an increasing diversity of operating systems and hardware. It's difficult to filter through the development and usage discussions to identify how to make it work on a certain platform. inkscape-testers would provide such a forum and a way to organize the collection and distribution of this information.
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.
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. 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.
For a marketing community, I don't think the time is quite right; our marketing efforts are already meeting and exceeding our expectations, and the amount of resources needed is limited and generally only comes into play for the short period around a release.
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?
Bryce
Bryce Harrington wrote:
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?
Well, I don't remember who had the quote, but I'll paraphrase: "Never start a mailing list unless you have to." I don't think that the amount of traffic caused by testing e-mails has overwhelmed -devel yet... so, I would say that it might a bit premature yet.
--Ted
On Thu, Aug 04, 2005 at 02:34:01PM -0700, Ted Gould wrote:
Bryce Harrington wrote:
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?
Well, I don't remember who had the quote, but I'll paraphrase: "Never start a mailing list unless you have to." I don't think that the amount
*Grin* I think that was me quoting jmz. ;-)
of traffic caused by testing e-mails has overwhelmed -devel yet... so, I would say that it might a bit premature yet.
I would argue the opposite. I think we've definitely achieved enough sustained discussion of QA topics like usability, testing, and so forth, that a separate mailing list would be viable.
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.
Bryce
On 8/4/05, Bryce Harrington <bryce@...260...> wrote:
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?
I really don't think it's necessary. The -user works well because it allows users to explain Inkscape tricks to each other, which not all devs are interested in. But even that list has its downside, as quite often I see there complaints and bug reports that the devs really should see. The same will be even more true for -testing. Simply put, all devs must care about testing by definition, so I see no reason for a person to be on one list and not the other, and therefore I see no reason for a separate list at all.
Especially with this broad definition:
sustained discussion of QA topics like usability, testing, and so forth,
Usability is definitely a topic for ALL devs (and users) to discuss.
On Thu, Aug 04, 2005 at 07:24:24PM -0300, bulia byak wrote:
On 8/4/05, Bryce Harrington <bryce@...260...> wrote:
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?
I really don't think it's necessary. The -user works well because it allows users to explain Inkscape tricks to each other, which not all devs are interested in. But even that list has its downside, as quite often I see there complaints and bug reports that the devs really should see. The same will be even more true for -testing. Simply put, all devs must care about testing by definition, so I see no reason for a person to be on one list and not the other, and therefore I see no reason for a separate list at all.
No, you are making some broad assertions, but you are overlooking some key points.
First, not all developers care about testing. In fact, on multiple ocassions I have seen them actively discourage it (sometimes unintentionally, sometimes not.)
* Several people (including myself) have attempted to do performance analysis of Inkscape. Typically this seems to really irritate developers; I recall being chastised that I was wasting my time and should be doing coding on the algorithms or something instead. In an inkscape-tester group such work could be conducted without directly irritating developers.
* Another good example was your reaction to my posting of warnings found by the test harness. You remarked, "I'm quite tired of seeing these warnings and complaints." As I'd only posted a couple of reports, I found this surprising and rather discouraging. Since then I've held off on posting updates, and think that an inkscape-tester list would be a more inviting place to post them.
* A more recent example was when I expressed interest in testing cairo in Inkscape. This was quite actively discouraged, because developers didn't want to think at all about cairo issues until cairo was sufficiently perfect that they could plug it in. Ironically, the cairo developers themselves don't want to think about those issues until it is plugged into an application. A group dedicated to testing would be able to conduct this analysis without getting so directly dismissed by developers.
Second, you say that "see no reason for someone to be on one list but not the other". This is clearly a poor assumption:
* Some people are quite willing to help with testing but won't be interested in regular developer discussion. Even if all developers were interested in testing, not all testers will be interested in development!
* As shown above, some Inkscape developers do not view testing as important. Some developers like you and me do want to have visibility into all aspects of quality control, but others simply want to focus on their particular features they're interested in. If their are quality problems with their code, they'd rather someone approach them directly, rather than having to watch all of the general testing discussion.
* Not all traffic on a testing list would be bug reports. Indeed, that's what we have the bug tracker for. Much discussion would go into writing testing scripts, or organizing who should test what features, or questions about inkscape usage that would simply further irritate developers to have to see.
Third, you appear to consider the only reason to establish a new list is to segregate traffic, as if the only purpose of separate lists is as bins for email. A mailing list is more than just a collection of emails, it is a community, and as such will have certain sociological behaviors, mindsets, and patterns. Even if there was a 100% overlap between inkscape-devel and inkscape-tester, the identity that people would take into that group would be distinct.
People have different "behavioral modes" when in different kinds of group settings. When you and your friends go to a wedding, you will behave one way, when you go to work you'll behave another way, and when you are going out for beers you'll act a third way. It may be exactly the same people in each situation, but the group setting will establish a different kind of focus.
I believe the same would happen if we established an inkscape-tester group. A group identity with a focus on testing would emerge, and activities would organize themselves around testing, perhaps in ways much different from what could be attained if the same people attempted to work as a subsidiary of inkscape-devel.
Quality improvement has been a long objective of mine. When I got involved with Sodipodi, one of the first things I did was to set up processes for using the bug tracker to help increase the stability of the codebase. We brought these same processes over to Inkscape, and look at how much benefit they've brought. Before we started this process, crashes were commonplace, yet today they are very rare, and when they inevitably do occur, the process we have enables them to get quickly recorded and bubbled up to the top of the list for intense focus and typically rapid fix.
Inkscape is also extremely well known for its usability, and this is directly attributed to our open development processes, that helps users get directly involved in development. This was not accidental; this was one of the principle reasons for our fork in the first place. You yourself were one of the earliest beneficiaries of this policy, as it resulted in enabling you to get very involved in improving the keyboard shortcuts.
I've also put a lot of thought into systematizing our release process over many releases, integrating a lot of people's ideas to help give us a system that matches to what we as a group are comfortable with, and that generally gives us much control over the quality of our releases.
I think there are still more areas where we can achieve great improvements in the quality of Inkscape. Performance, automated regression testing, organized usability analysis, experimental testing, interoperability checking, test/tool development, and more. Just as we needed to make some aggressive changes to the project to enable us to reach new levels of quality, so to do I think that forming a testing focused group will enable the project to achieve these other aims.
Anyway, it's too bad that the three responses so far have not been supportive to the idea. I feel very strongly that this change would benefit Inkscape, just as adopting a bug tracker helped stability, establishing open development processes helped usability, and establishing a release process helped installability. Am I the only person that thinks we could benefit from an organized testing community?
Bryce
On 8/5/05, Bryce Harrington <bryce@...260...> wrote:
- A more recent example was when I expressed interest in testing cairo
in Inkscape. This was quite actively discouraged, because developers didn't want to think at all about cairo issues until cairo was sufficiently perfect that they could plug it in. Ironically, the cairo developers themselves don't want to think about those issues until it is plugged into an application. A group dedicated to testing would be able to conduct this analysis without getting so directly dismissed by developers.
I'm pretty sure that Cairo will succeed only when they have several serious applications running on top of it. Testing on tranclucent butterflies won't give us decent perfomance and a mature renderer.
The real question is who among developers has enough time to deal with Cairo stuff, which means at least
a) patching the code in a separate branch; b) communicating with testers and their bug reports.
Quality improvement has been a long objective of mine.
Well, I think many people have noticed an increased number of brown paper bag releases over last year. Lots of really nice software projects release some, say, x.x.x version, which is followed by a x.x.x.x one within several days: K3B, Evolution, The GIMP, Scribus and, sadly, Inkscape.
This happens, because the more people use some application, the more bugs are discovered. Within current approach to FOSS development this will never change.
This I personally would definitely like to see a brider merging of Quality & Assurance into FOSS development model. It does help to release less buggy software.
If we have human resources to go through the full Q&A cycle before each release, then some inkscape-testing@ will be a good place. If we don't, we need to find some other safe ways to improve quality of releases and communication between users and developers within inkscape-devel@ and inkscape-users@...233...
Alexandre
On 8/4/05, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
Well, I think many people have noticed an increased number of brown paper bag releases over last year. Lots of really nice software projects release some, say, x.x.x version, which is followed by a x.x.x.x one within several days: K3B, Evolution, The GIMP, Scribus and, sadly, Inkscape.
This happens, because the more people use some application, the more bugs are discovered.
Right - so older versions didn't have bugfix followups not because they were "better", but simply because too few users found too few of their bugs.
Consider Inkscape 0.42. If we didn't have 50K downloads in the first few days, most problems fixed in 0.42.1 would remain undiscovered for months, and 0.42.1 most likely would not happen at all.
So, I see absolutely no problem with a bugfix release at this point. All it means is that we're growing. If we had the same userbase as we do now but for 0.42 prereleases, we'd have a better 0.42 and no need for 0.42.1. But this also means that we WILL have this large userbase for 0.43 prereleases, and thus a good chance to make a better 0.43.
On 8/4/05, bulia byak <buliabyak@...400...> wrote:
Consider Inkscape 0.42. If we didn't have 50K downloads in the first few days, most problems fixed in 0.42.1 would remain undiscovered for months, and 0.42.1 most likely would not happen at all.
As an example, 0.41 had a number of VERY serious bugs (e.g. command line export was entirely broken). However due to the small userbase these were discovered quite some time after the release, and we never bothered to make a 0.41.1 (though we really should have done).
So at this point of time, I'm MUCH more interested in seeing more of the devs work on the recent bugs in our tracker. This is critical for 0.42.1. May I ask that EACH developer go through the since-0.42 bugs and comment on as many of them as possible? Please? We can resume discussing the -testing list after 0.42.1 is out :)
On 8/4/05, Bryce Harrington <bryce@...260...> wrote:
First, not all developers care about testing. In fact, on multiple ocassions I have seen them actively discourage it (sometimes unintentionally, sometimes not.)
Hmm, even if this so, I don't think it's the behavior we should encourage.
- Several people (including myself) have attempted to do performance
analysis of Inkscape. Typically this seems to really irritate developers; I recall being chastised that I was wasting my time and should be doing coding on the algorithms or something instead.
I don't remember this, but in any case, it's not something I'd approve. I and I think most other devs are very interested in performance testing and profiling. I have always said so. In fact I do some simple tests myself from time to time and report if they discover notable changes.
- Another good example was your reaction to my posting of warnings found
by the test harness. You remarked, "I'm quite tired of seeing these warnings and complaints."
Sorry, you have entirely misread me. All I wanted to say is, "PLEASE someone finally fix these problems", not "please stop reporting them". I was tired of seeing them _in my compiles_, not on the list! In fact I was even GLAD that someone reported them and thus gave me the pretext to whine about these warnings, as I was too lazy to bring up the subject myself.
As I'd only posted a couple of reports, I found this surprising and rather discouraging. Since then I've held off on posting updates, and think that an inkscape-tester list would be a more inviting place to post them.
If you ever again find my comments weird or discouraging in any way, please don't hesitate to ask me directly. I may not always be able to express my intent entirely clearly.
- A more recent example was when I expressed interest in testing cairo
in Inkscape. This was quite actively discouraged,
Sorry, wrong again. We just agreed that it's premature to integrate it into Inkscape even as an option, at this point. But as for testing, I'm all for it. I would be VERY interested to see more sample renderings and render timings of Cairo.
- Some people are quite willing to help with testing but won't be interested in regular developer discussion.
It's very hard to make such a distinction, IMHO.
Even if all developers were interested in testing, not all testers will be interested in development!
They don't have to read it. They can just post their results and respond to questions, and skip the rest. The reason why this is best done on devel is that it's the only more or less guaranteed way to catch the attention of the specific developer who's responsible for this part of code, and to respond to his specific questions.
If their are quality problems with their code, they'd rather someone approach them directly, rather than having to watch all of the general testing discussion.
Testers often have no way of knowing whose particular problem is this. So they can't do better than to post to the list that ALL devs read.
- Not all traffic on a testing list would be bug reports. Indeed, that's what we have the bug tracker for. Much discussion would go into writing testing scripts
Which is where devs' help is important. Nobody can know better than me how to test my feature.
Even if there was a 100% overlap between inkscape-devel and inkscape-tester, the identity that people would take into that group would be distinct.
In practice this would most likely mean that most of posts will be cross-posted to both lists, as now many posts are cross-posted to devel and user.
A group identity with a focus on testing would emerge
I guess what may result from this is that testers will be discouraged by (perceived) lack of attention from devs. For a typical tester, the ultimate goal is not to participate in a community but to have some issue fixed, and for that, the best (and the only) way is to reach the right developer.
In short, I remain convinced that testing is an absolutely unseparable part of development, so I don't think a separate list (even with the same membership) is such a good idea. Even for the user/devel pair, there's a lot of crossposting and misplaced threads, though I think these twp lists will grow more separate with time. But with testing, I just don't see any reason for it to grow significantly separate from development, ever. (If it does, I don't think it bodes well for the quality of the project.)
On Thu, 2005-08-04 at 21:56 -0300, bulia byak wrote:
On 8/4/05, Bryce Harrington <bryce@...260...> wrote:
First, not all developers care about testing. In fact, on multiple ocassions I have seen them actively discourage it (sometimes unintentionally, sometimes not.)
Hmm, even if this so, I don't think it's the behavior we should encourage.
- Several people (including myself) have attempted to do performance
analysis of Inkscape. Typically this seems to really irritate developers; I recall being chastised that I was wasting my time and should be doing coding on the algorithms or something instead.
I don't remember this, but in any case, it's not something I'd approve. I and I think most other devs are very interested in performance testing and profiling. I have always said so. In fact I do some simple tests myself from time to time and report if they discover notable changes.
- Another good example was your reaction to my posting of warnings found
by the test harness. You remarked, "I'm quite tired of seeing these warnings and complaints."
Sorry, you have entirely misread me. All I wanted to say is, "PLEASE someone finally fix these problems", not "please stop reporting them". I was tired of seeing them _in my compiles_, not on the list! In fact I was even GLAD that someone reported them and thus gave me the pretext to whine about these warnings, as I was too lazy to bring up the subject myself.
As I'd only posted a couple of reports, I found this surprising and rather discouraging. Since then I've held off on posting updates, and think that an inkscape-tester list would be a more inviting place to post them.
If you ever again find my comments weird or discouraging in any way, please don't hesitate to ask me directly. I may not always be able to express my intent entirely clearly.
- A more recent example was when I expressed interest in testing cairo
in Inkscape. This was quite actively discouraged,
Sorry, wrong again. We just agreed that it's premature to integrate it into Inkscape even as an option, at this point. But as for testing, I'm all for it. I would be VERY interested to see more sample renderings and render timings of Cairo.
- Some people are quite willing to help with testing but won't be interested in regular developer discussion.
It's very hard to make such a distinction, IMHO.
Even if all developers were interested in testing, not all testers will be interested in development!
They don't have to read it. They can just post their results and respond to questions, and skip the rest. The reason why this is best done on devel is that it's the only more or less guaranteed way to catch the attention of the specific developer who's responsible for this part of code, and to respond to his specific questions.
If their are quality problems with their code, they'd rather someone approach them directly, rather than having to watch all of the general testing discussion.
Testers often have no way of knowing whose particular problem is this. So they can't do better than to post to the list that ALL devs read.
- Not all traffic on a testing list would be bug reports. Indeed, that's what we have the bug tracker for. Much discussion would go into writing testing scripts
Which is where devs' help is important. Nobody can know better than me how to test my feature.
Even if there was a 100% overlap between inkscape-devel and inkscape-tester, the identity that people would take into that group would be distinct.
In practice this would most likely mean that most of posts will be cross-posted to both lists, as now many posts are cross-posted to devel and user.
A group identity with a focus on testing would emerge
I guess what may result from this is that testers will be discouraged by (perceived) lack of attention from devs. For a typical tester, the ultimate goal is not to participate in a community but to have some issue fixed, and for that, the best (and the only) way is to reach the right developer.
In short, I remain convinced that testing is an absolutely unseparable part of development, so I don't think a separate list (even with the same membership) is such a good idea. Even for the user/devel pair, there's a lot of crossposting and misplaced threads, though I think these twp lists will grow more separate with time. But with testing, I just don't see any reason for it to grow significantly separate from development, ever. (If it does, I don't think it bodes well for the quality of the project.)
I don't think that the tester list would separate testing from development. Development will always have some level of testing and reporting. This testing list seems to be more focused on heavy testing, setting up test systems, feeds of daily tests on Inkscape, packaging issues, etc. If anything, the dev. list will serve as a hub to then send ppl. to the testing list.
We have to face that our project is growing and sometimes we need to subdivide tasks, etc...I think this sounds like a good idea.
Jon
Bryce Harrington wrote:
establishing a release process helped installability. Am I the only person that thinks we could benefit from an organized testing community?
Not exactly, and I would really like to help work on some automated tests (maybe a tester of tests :) and like to help out on testing Cairo stuff but Bulia makes a good point and I'll hold more thoughts until 0.42.1 is out. John
On Thu, Aug 04, 2005 at 05:26:53PM -0700, Bryce Harrington wrote:
- Several people (including myself) have attempted to do performance
analysis of Inkscape. Typically this seems to really irritate developers; I recall being chastised that I was wasting my time and should be doing coding on the algorithms or something instead. In an inkscape-tester group such work could be conducted without directly irritating developers.
No reference is given to the conversation in question, but I'd guess that the "chastiser" was emphasizing the importance of algorithm choice when trying to improve performance: this is standard advice (second to to "use a profiler before touching the code"), and is mentioned in the comp.lang.c FAQ answer on performance tuning (http://www.eskimo.com/~scs/C-faq/q20.13.html).
Another fairly well-known source (Knuth, perhaps?) says that the first rule of optimization is "don't do it"; I think because of the cost in readability, bugginess, developer time, and the fact that most code isn't performance-critical (80% of program time being spent in 10% of the code, or whatever percentages). (I think the second & third rules, from the same source, are "use a profiler first" and "optimize algorithms rather than code".)
Testing for performance regressions would certainly be valuable.
pjrm.
On Mon, Aug 08, 2005 at 03:01:01PM +1000, Peter Moulder wrote:
On Thu, Aug 04, 2005 at 05:26:53PM -0700, Bryce Harrington wrote:
- Several people (including myself) have attempted to do performance
analysis of Inkscape. Typically this seems to really irritate developers; I recall being chastised that I was wasting my time and should be doing coding on the algorithms or something instead. In an inkscape-tester group such work could be conducted without directly irritating developers.
No reference is given to the conversation in question, but I'd guess that the "chastiser" was emphasizing the importance of algorithm choice when trying to improve performance: this is standard advice (second to to "use a profiler before touching the code"), and is mentioned in the comp.lang.c FAQ answer on performance tuning (http://www.eskimo.com/~scs/C-faq/q20.13.html).
Yes, that's accurate according to my memory. I don't recall whether the conversation was in IRC or email, but it probably doesn't matter.
(Ironically, my changed actually also resulted in *simplifying* e.g. by removing duplicate assignments and combining redundant logical checks.)
The main point I took from this comment was that the optimization problems were probably systemic rather than just implementational, and thus that replacement of the code (i.e., with Cairo) would be a better focus of effort than continuing with micro-optimizations.
In any case, I think the important thing is that we really need to develop a game plan for how to tackle performance optimization. This is something that we certainly cannot depend on Cairo to give us; presently the issue is *worse* with Cairo. ;-)
I think that even modest planning for measuring and tackling performance will not only scratch our own itch within Inkscape, but will address a deep need in Cairo and in OSS as a whole.
Does anyone have ideas for how we can approach this?
Bryce
On Thu, 4 Aug 2005, bulia byak wrote:
...
sustained discussion of QA topics like usability, testing, and so forth,
Usability is definitely a topic for ALL devs (and users) to discuss.
I'm really glad you said that. :)
Accessibility is for everyone too.
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
On Fri, Aug 05, 2005 at 04:15:38PM +0100, Alan Horkan wrote:
On Thu, 4 Aug 2005, bulia byak wrote:
...
sustained discussion of QA topics like usability, testing, and so forth,
Usability is definitely a topic for ALL devs (and users) to discuss.
I'm really glad you said that. :)
Accessibility is for everyone too.
Hi Alan,
We've talked about accessibility before; do you know if there are any tests or projects that investigate accessibility issues?
Bryce
Subject: Accessibility (a11y) for all [was Re: Usability for All]
I've CC'ed the user list because there is a lot we can all learn and relatively easy ways you can help test the accessibility (a11y) of Inkscape and it can have all kinds of knock on benefits.
On Fri, 12 Aug 2005, Bryce Harrington wrote:
Date: Fri, 12 Aug 2005 22:53:20 -0700 From: Bryce Harrington <bryce@...260...> To: Alan Horkan <horkana@...44...> Cc: inkscape-devel@lists.sourceforge.net, inkscape-user@lists.sourceforge.net Subject: Re: Usability for All [was Re: [Inkscape-devel] Proposal for inkscape-testers]
On Fri, Aug 05, 2005 at 04:15:38PM +0100, Alan Horkan wrote:
On Thu, 4 Aug 2005, bulia byak wrote:
...
sustained discussion of QA topics like usability, testing, and so forth,
Usability is definitely a topic for ALL devs (and users) to discuss.
I'm really glad you said that. :)
Accessibility is for everyone too.
Hi Alan,
We've talked about accessibility before; do you know if there are any tests or projects that investigate accessibility issues?
Accessibility is one of those things I've always meant to learn more about. Anytime I feel my hands getting sore from too much typing I hope I feel bad about making things more accessible because I'm someday I will probably need it.
The basics you need to consider and which also feed into usability are
1) Can I do everything using only the keyboard? 2) Can everything be themed properly? 3) Can the standard assisitive technologies be used?
1) The point is not that you would necessarily want to work using only a keyboard but making it possible has important side effects.
The more it is possible to do without depending on the two button mouse the better. We will want to be careful to make Inkscape work well with Pen input devices anyway but it is something all developers should be careful about. (Apple ship with a single button mouse by default because of the discipline it forces on developers more than anything else.)
This is something all users can help out with and improvements here should help make Inkscape even better to use when you do have both the mouse and keyboard in action. All you need to do is unplug your mouse (or instead unplug you keyboard and do not use the right click or wheel) and see what you can do. If you keep a diary or log as you go and jot down any problems you might encounter or try and identify any tasks which are extremeley tedious and repetative you could really help find areas which could be improved.
2) High Contrast themes are important. People with vision difficulties, even blind users will want to draw things occasionally. http://dub.washington.edu/projects/ic2d/
3) Standard assistive technologies include Gok, Gnopernicus, Dasher and I'm sure there are more I don't know about yet. Don't make any assumptions about these applications before you have tried them (dont really have time to explain any better).
Accessibility makes it all the more important to use standard widgets most of which have already been accessible whereas rolling your own "innovative" widgets can create a nasty new variety of problems. If custom widgets must be created it is better for us all in the long run to push them down into toolkit. Inkscape has been very good about this and I just want to reassure the developers it is the right thing to do.
Developers should probably check out the two applications at-spi and at-poke, "at" is short for Accessibility Toolkit (also referred to as ATK) and these applications will help you to evaluate your software.
If you are interested in Accessiblity I think it will be important to have a build --with-gnome because I believe including those extra libraries draws in a stack of ATK related libraries which can have some benefits. Of course I care about portability too (portability both to other operating systems and future versions of the toolkits we use) so it is always better when these features are cleanly seperable.
I wrote this all from memory and it summarises a lot of what I have learned about accessiblity over the years. If you ask the accessibility team and read through their documentation I expect there is a lot more you can learn but what I have already mentioned should resemble the Frequently Asked Questions.
Hope that helps.
Sincerely
Alan Horkan Jack of all trades, master of none ;)
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
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.
What I have seen on the lists is the equation of "tester" and "user," although in reality this is not the same. Of course people need to try it out, find bugs, etc. But there is also metrics-style testing, which can be purely performance measures, bug counts, memory consumption, footprint, clicks-per-operation, DTP-style testing, etc..... This can be some very arcane conversation. It is possible for a person to do this, and not be an Inkscape user at all.
The Venn diagrams overlap, but they are not one-to-one. If we keep these communities together in order to grow the synchronicity, then the members must be ready to participate in the conversation. We have had such good luck so far with our two lists because all of the developers are users.
Actually, I would think there would be more incentive to spin off something like "inkscape-packagers", as the issues dealing with architectures and distributions can be totally foreign to anyone else.
Bob
On Fri, Aug 05, 2005 at 10:07:18AM -0500, Bob Jamison wrote:
What I have seen on the lists is the equation of "tester" and "user," although in reality this is not the same. Of course people need to try it out, find bugs, etc. But there is also metrics-style testing, which can be purely performance measures, bug counts, memory consumption, footprint, clicks-per-operation, DTP-style testing, etc..... This can be some very arcane conversation. It is possible for a person to do this, and not be an Inkscape user at all.
I agree. I think that user, developer, and _tester_ are three very different roles. For a small open source project, the first two categories may be difficult to separate, but as the project grows the roles become notably different. For Inkscape I think we've far passed that point. I think we've reached the point at which 'tester' can be distinguished from either 'developer' or 'user', as well.
After looking long and hard at how testing works in open source projects, I also think that you can distinguish between "natural testing" as occurs as part of routine use of the program, and "synthetic testing" that is done through more artificial means such as memory consumption measures, clicks-per-operation, etc. These sorts of measurements can definitely be done by someone with a non-techical background, but as you point out, they're definitely beyond ordinary user behavior. I hope we can find people with this mindset, to help us in these areas. :-)
Bryce
Quoting Alan Horkan <horkana@...44...>:
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.
Yes, we will need people to take leadership roles. This tends to happen organically on -devel, although I don't see so much of it on -user yet. I had been hoping we'd see some power users (aside from bulia) emerge and start mentoring the others.
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).
Unfortunately part of the problem was that many people decided to wait for the "final" release before trying it out.
Which is a consequence of normal human psychology, I think. I'm not sure how to encourage users to "take the grenade" of the prereleases. Maybe encouraging a testing community, as such, could help.
Ideally I would like to see a deliberate usability review of some form take place as part of every release cycle.
Yes. All for that.
If enough Developers lurk and occasionally respond to issues on the testing list it could work.
Yeah. I think all the core developers should be subscribed to the testing list, at least.
-mental
mental@...3... wrote:
Which is a consequence of normal human psychology, I think. I'm not sure how to encourage users to "take the grenade" of the prereleases. Maybe encouraging a testing community, as such, could help.
Jabber and IRC are good for this. Near the end of the 0.42 cycle, almost every newbie that popped in was encouraged to try CVS. This behavior is possible because Inkscape has readily available nightly builds and always functional CVS. Perhaps one of the strongest features of the project! Advertising this feature more publicly as the userbase grows could really turn things up a notch.
Aaron Spike
On Fri, 5 Aug 2005 mental@...3... wrote:
Date: Fri, 05 Aug 2005 13:43:45 -0400 From: mental@...3... To: Alan Horkan <horkana@...44...> Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Re: [Inkscape-user] Proposal for inkscape-testers
Quoting Alan Horkan <horkana@...44...>:
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.
Yes, we will need people to take leadership roles. This tends to happen organically on -devel, although I don't see so much of it on -user yet. I had been hoping we'd see some power users (aside from bulia) emerge and start mentoring the others.
I suppose it needs a clear sense of policy: be nice, answer questions, make suggetions etc.
The it takes one the existing developer leaders to recognise and thank a user for actively answering questions, encourage them and then informally dub them moderator or such-like and ask them to take responsibility for reminding people to follow policy (see above: be nice...) and making sure things get moved to the developer list when needed and whatever else is really needed.
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).
Unfortunately part of the problem was that many people decided to wait for the "final" release before trying it out.
\0/
my bad, mea cupla, guilty as charged!
(that ascii art is is me with my hands up in the air ;)
downloading the latest 0.42.x test release now...
Which is a consequence of normal human psychology, I think. I'm not sure how to encourage users to "take the grenade" of the prereleases. Maybe encouraging a testing community, as such, could help.
A quick short list of "smoke tests" which I think mozilla had/has might help.
Maybe a web form
Username [ ] Inkscape [version] Platform [ ]
Test 1 [/] [ Comment ] Test 2 [/] [ Comment ] Test 3 [/] [ Comment ]
[Submit]
or summink like that to make feedback more visible and have a graph/chart generate from it?
Ideally I would like to see a deliberate usability review of some form take place as part of every release cycle.
Yes. All for that.
If enough Developers lurk and occasionally respond to issues on the testing list it could work.
Yeah. I think all the core developers should be subscribed to the testing list, at least.
Hope this testing list works out.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
On Fri, Aug 05, 2005 at 01:43:45PM -0400, mental@...3... wrote:
Quoting Alan Horkan <horkana@...44...>:
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.
Yes, we will need people to take leadership roles. This tends to happen organically on -devel, although I don't see so much of it on -user yet. I had been hoping we'd see some power users (aside from bulia) emerge and start mentoring the others.
Actually, there have been a few notables emerge from the -user group. They've shown strong leadership in several projects related to documentation, establishment of an art community, and gaining us a pretty kick ass about screen. :-)
I think this release was unusually rough because of the longer development time.
Unfortunately part of the problem was that many people decided to wait for the "final" release before trying it out.
Which is a consequence of normal human psychology, I think. I'm not sure how to encourage users to "take the grenade" of the prereleases. Maybe encouraging a testing community, as such, could help.
This is also my take on it.
Over the past few months I've been writing a technical paper for the Pacific Northwest Software Quality Conference about the NFSv4 testing experiences, and as part of this I've been reading a lot of research papers about Open Source, testing, and community organization.
It's well known among professional, commercial software testers that a "tester" and a "user" have very different approaches and motivations. The user basically just wants to get their work done, and builds on an assumption that the software is problem-free; if not, they report it. A person with a testing mindset, on the other hand, goes in with the assumption that the software is a little puzzle to figure out. How can you break it?
Now, a commercial software company would probably note that the testers seem like the right way to do QA, so they focus exclusively on that type of testing. It's easy to control, can be planned out in detail, etc.
For Open Source, though, the "user testing" is the cheaper approach. It's particularly valuable in that it doesn't _need_ to be controlled, it just happens, and it scales directly with the size of the userbase.
However, I believe both of these approaches can work together in a complementary fashion, and compensate for each other's weaknesses.
With NFSv4, it's interesting because we have both the users (who randomly report problems as they're setting it up and using it), and folks that participate strictly in doing formalized testing, which we've taken to calling "synthetic testing".
I was presenting about this work to some users in the film industry and showed some graphs of how one tester had pushed NFS by creating one directory and putting as many files as possible into it. This was quite an effective way to scare out bugs, and as he went he kept running into limits that exposed unusual problems within the kernel that the developers had never known about, but were quick to explore and solve. By the time of the presentation they'd reached 1.6 million files per directory, and I remarked that the testers and developers still weren't happy with that number. One of the audience chuckled and said, "I think our usage may have millions of files, but certainly not in one directory! This is great that someone is testing it this way and solving all the bugs, because it's definitely not something we users would be worrying about for a long time."
It's very interesting to read what other researchers have written about testing in open source projects, particularly because the things they point out doing are mostly things Inkscape already does: Nightly builds, a central bug tracker, a triaging process, an authority to declare when the release is ready, etc.
Research into synthetic testing coupled with standard open source user testing is scarcer and harder to find, however the evidence exists to show that while it can be difficult to do, it can really pay off big time.
Hearing Mozilla talk about this in specifics, and how they had a focused testing team, really showed how much that this sort of approach can have a huge impact on the quality of a multi-platform open source application.
Bryce
On Fri, 2005-08-05 at 23:39 -0700, Bryce Harrington wrote:
On Fri, Aug 05, 2005 at 01:43:45PM -0400, mental@...3... wrote:
Quoting Alan Horkan <horkana@...44...>:
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.
Yes, we will need people to take leadership roles. This tends to happen organically on -devel, although I don't see so much of it on -user yet. I had been hoping we'd see some power users (aside from bulia) emerge and start mentoring the others.
Actually, there have been a few notables emerge from the -user group. They've shown strong leadership in several projects related to documentation, establishment of an art community, and gaining us a pretty kick ass about screen. :-)
I think this release was unusually rough because of the longer development time.
Unfortunately part of the problem was that many people decided to wait for the "final" release before trying it out.
Which is a consequence of normal human psychology, I think. I'm not sure how to encourage users to "take the grenade" of the prereleases. Maybe encouraging a testing community, as such, could help.
This is also my take on it.
Over the past few months I've been writing a technical paper for the Pacific Northwest Software Quality Conference about the NFSv4 testing experiences, and as part of this I've been reading a lot of research papers about Open Source, testing, and community organization.
It's well known among professional, commercial software testers that a "tester" and a "user" have very different approaches and motivations. The user basically just wants to get their work done, and builds on an assumption that the software is problem-free; if not, they report it. A person with a testing mindset, on the other hand, goes in with the assumption that the software is a little puzzle to figure out. How can you break it?
Now, a commercial software company would probably note that the testers seem like the right way to do QA, so they focus exclusively on that type of testing. It's easy to control, can be planned out in detail, etc.
For Open Source, though, the "user testing" is the cheaper approach. It's particularly valuable in that it doesn't _need_ to be controlled, it just happens, and it scales directly with the size of the userbase.
However, I believe both of these approaches can work together in a complementary fashion, and compensate for each other's weaknesses.
With NFSv4, it's interesting because we have both the users (who randomly report problems as they're setting it up and using it), and folks that participate strictly in doing formalized testing, which we've taken to calling "synthetic testing".
I was presenting about this work to some users in the film industry and showed some graphs of how one tester had pushed NFS by creating one directory and putting as many files as possible into it. This was quite an effective way to scare out bugs, and as he went he kept running into limits that exposed unusual problems within the kernel that the developers had never known about, but were quick to explore and solve. By the time of the presentation they'd reached 1.6 million files per directory, and I remarked that the testers and developers still weren't happy with that number. One of the audience chuckled and said, "I think our usage may have millions of files, but certainly not in one directory! This is great that someone is testing it this way and solving all the bugs, because it's definitely not something we users would be worrying about for a long time."
It's very interesting to read what other researchers have written about testing in open source projects, particularly because the things they point out doing are mostly things Inkscape already does: Nightly builds, a central bug tracker, a triaging process, an authority to declare when the release is ready, etc.
Research into synthetic testing coupled with standard open source user testing is scarcer and harder to find, however the evidence exists to show that while it can be difficult to do, it can really pay off big time.
Hearing Mozilla talk about this in specifics, and how they had a focused testing team, really showed how much that this sort of approach can have a huge impact on the quality of a multi-platform open source application.
That is so great...you know what would be great is a white-paper presenting a good practice approach to testing for open source projects...I think that would be very valuable to the open source world.
Maybe OSDL could sponsor that...it would rule :)
Jon
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, Aug 05, 2005 at 03:49:25PM +0100, Alan Horkan wrote:
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.
*Nod* Very true; on the other hand, of any project, Mozilla seems to have the least problem with creating too many mailing lists, so at least from that standpoint, I think they serve as a good model for us. ;-)
Also, from a testing perspective, Mozilla is a good model; after all they are the maintainers of both Bonzai and Tinderbox, and are engaged in development of various other tools including an automated crash reporter thingee.
I think Inkscape can stand to benefit from their lessons learned, and coupled with our own strengths I think we can even go beyond them in some ways. :-)
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.
There actually wasn't much emphasis placed on leadership roles. I gathered that it definitely was necessary for there to be someone with "a passion" to help keep the community active and to serve as the "grit of sand that makes the pearl", but they did not appear to be hierarchical organizations or anything.
In any case, I think Inkscape has enough people with strong interest in testing that this should not be an issue.
- 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).
Possibly, but my gut tells me otherwise.
First off, there is benefit to having long development cycles, so I do not think we will be able to assert that all development cycles must be short; we must have a testing process that allows us to intermix long and short development cycles and still produce a high quality product.
Second, a large portion of our issues occurred due to packaging issues. By definition, all of our most active developers do most of their testing off of CVS rather than packages. Thus, we definitely cannot expect that they will catch all of these types of issues simply as a matter of course. We need a process that is a bit more organized for packaging issues.
Third, I would not characterize this release as "rushed". There were several points where I thought to myself, "Dammit, let's just get the release out!" and wanted to override people who were cautioning us to take more time. I had a definite personal interest in seeing the release occur on a specific date (the day I presented Inkscape at OLS.) But I opted instead to be very conservative and adhere to all of these concerns. If anything, I think this was the *most* conservative release. Yet despite this, we still ended up needing a point release...
It's been said that the need for a point release was mainly due to the increased size of the userbase, and that in past releases we probably wouldn't have noticed the issues quite so quickly. This is probably true. Yet, unfortunately we cannot use that as an excuse; we must plan with the assumption that our userbase will increase, which means that we must gain a stronger QA process.
- 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.
Alan, I think you're right on the money here. Would you mind spending a couple hours to develop a checklist for us? If you do this, I will commit to ensuring that the inkscape-tester group looks at it in every release henceforth.
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.
Agreed.
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.
For a project as large as Mozilla, part of the draw (as mentioned at their presentation), is the opportunity to make an impact on a project that has such a wide reach to so many people.
Inkscape is still not quite in that class, although with the 0.42 release we certainly do reach an incredible number of people.
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.
Yes, you're right. Oftentimes testing is also treated as a finite task (e.g., automated testing is often treated as something you can set up and walk away from; when in reality, you must constantly be adding new tests and environments in order for it to remain relevant.)
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.
Yes, I agree. I think it's been roughly a year since inkscape-user was established, so I don't think we run the risk of creating "too many lists".
Even if no one else is interested, I will be dedicating myself to posting information to inkscape-tester on a regular basis, so I don't think this is going to impose much risk.
I would love to see this develop into a vibrant, dedicated community of people with an interest in seeing Inkscape grow more robust, with higher performance, and better ability to conform to the standards.
Bryce
On Aug 12, 2005, at 11:20 PM, Bryce Harrington wrote:
On Fri, Aug 05, 2005 at 03:49:25PM +0100, Alan Horkan wrote:
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.
Alan, I think you're right on the money here. Would you mind spending a couple hours to develop a checklist for us? If you do this, I will commit to ensuring that the inkscape-tester group looks at it in every release henceforth.
Right off hand, this sort of thing makes me think "custom XML!"
In doing some such list, it can be very handy to have it in logical XML form. Among other things, this can help with multiple users updating and keeping it in CVS.
Just get a quick format that splits things up logically, then use XLST to munge it into some nice other format for viewing, treating the XML as source. If you need a hand with this, just let me know.
participants (12)
-
unknown＠example.com -
Aaron and Sarah Spike -
Alan Horkan -
Alexandre Prokoudine -
Bob Jamison -
Bryce Harrington -
bulia byak -
John Taber -
Jon A. Cruz -
Jon Phillips -
Peter Moulder -
Ted Gould