See bottom-post:
Bryce Harrington wrote:
On Thu, Aug 04, 2005 at 07:24:24PM -0300, bulia byak wrote:
On 8/4/05, Bryce Harrington <bryce@...69...> 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
You ask "Am I the only person that thinks we could benefit from an organized testing community?"
No, I am for the idea in principle but can sense a fear of differentiating between -dev, -test and -user issues and the possibility of total confusion setting in with resulting antipathy.
But I for one would be in a testing process if there were one.
Regards
Adam