On Wed, 11 Oct 2006, Bryce Harrington wrote:
I don't know; I can certainly see how this is a valuable approach for a commercial product, where you have developers that don't really understand what the product needs to do, and need to set up strawmen and use cases in order to understand what to code.
I admire your optimism. Inkscape does have some useful contraints already, the SVG specification in particular helps set that up, and somewhat implies a Web audience (macromedia were always more web than adobe with their history in the print industry).
The idea of target users is complimentary to ideas like a Roadmap, which you dont strictly need but it helps people row in the same direction. The idea is more a way of clarifying the unspoken understandings developers already have, and that kind of information can make it easier for new developers to get on board. There are so many ideas that current developers know implictly but cannot pin down exactly that would take a while for someone new to the project to get the hang of
One of the things the idea of targer user helps with is knowing when something is easy enough. I'd use tile clones as an example of something that works but is too difficult for beginners but I think previous discussions already discovered lots of people found it difficult to use (and tutorials will certianly help but again a different question). It can also help with decisions with terminolgy and what level to pitch things at, or even accepting that Inkscape is not going to be suitable for someone who doesn't already know a bit about SVG or the difference between vector and raster graphics. (I'm reaching for examples, please forgive that they aren't great examples.)
I think another reason I dislike the idea of defining "target users" is that it facilitates the mentality that users and developers are two separate groups, and that users exist to define requirements for the developers to implement.
"requirements" is the wrong model, but being able to say Inkscape isn't aimed at kids does set a useful limit and gives groups such as OLPC a blessing to take the codebase in another direction rather than trying to turn Inkscape into something the developers know it is not well suited to.
(In reality the target users of OLPC have already resulted in strict technical requirements which means they have been encouraged to branch from the pre C++ versions of Inkscape but again I'm trying to find examples in terms of users and tasks.)
advantage of this requires that they *GET INVOLVED* - users realize their power through contributing, and those who do not participate won't be empowered.
As a user I like applications to look a certain way, the GNOME HIG gives me a much clearer way to express that. A better understanding of who the target inkscape users are also helps me contribute by letting me know the right path and not spend excessive time trying to make inappropiate suggestions or at least prioritise certain things to focus on.
company conference. A bunch of end user companies/governments spoke about their FOSS adoption and the question came up if they ever contributed back. EVERY ONE of them not only said they contributed back, but that they viewed the ability to contribute back as one of the big advantages to using FOSS.
They might have assumed that contributed back meant more than filing bugs and feature requests but your point is well taken, and I guess every release should hammer home that Inkscape is looking for new contributors.
having a few parallel projects - like the summer of code proposals - and a few developers dubbed as mentors might help in that regard, quite a few projects seem to be capitalising on the methodology used during the Google summer of code to draw in more contributors beyond those who got paid sponsorship.
(Getting very very sleepy, goodnight...)