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
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
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
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
> 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.
> > 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
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.