incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Dickinson <>
Subject Re: Jena documentation - new structure working notes
Date Thu, 17 Feb 2011 17:45:37 GMT
Hi Paolo,

On 17/02/11 15:49, Paolo Castagna wrote:
> I agree with the fact that there will be differences between number
> of users/developers, expert users/developers, contributors and finally
> committers, order of magnitudes difference.
> However, I don't see that as a good reason not to aim at moving people
> from being users to expert users/developers and, if possible, up to a
> point where they can help us developing new features, fixing bugs,
> submitting patches, improving performances, etc. and, overall,
> achieving more that what we can do (since we are a small number of
> very busy people with little bandwidth and limits).
Sorry, I still don't agree. Optimising primarily for the minority case
makes no sense to me. Yes we want to grow the Jena community, and I've
never said that that shouldn't be important in the new site design, but
developers will *always* be a small minority of the overall site users.
As an aside, more patches = more work for committers to review; qv. the
current discussion around the query termination patch.

> Also, now that I am thinking more about Jena users and developers...
> ... what's the difference between a Jena user and a Jena developer?
> I mean, Jena users are always developers, but they don't look at the
> Jena source code, they don't compile Jena, they simply use it as a
> library.
> Jena developers are different, they look at the source, they can
> find a bug and/or produce a patch for it, etc.
> Is this something important to keep in mind when we think about the
> content of the website?
Yes, it is, but, again I don't think it's the dominant use case.

Look. The problem at the moment is that we have a lot of content on, and the tdb/joseki/fuseki etc wikis, but it's really hard
to find stuff. *We* find it hard to find information. We get lots of
questions on (old) jena-dev that could easily be answered from already
available documentation, and I'm certain that we lose potential users
who just it too much of a mountain to climb to learn Jena.

A first step for migration, in my view, is to take the current
significant quantity of content and put it under the Apache umbrella.
Along the way, we can, and I propose should, do a bit of reorganization
so that we can start to increase usability and utility for the current
readers. I hear the concerns about getting too ambitious, but the
counter-balancing risk is we get another sub-optimal structure ossified

> I would probably tend to say that, so far, the documentation has been
> too focused on the Jena users and too little on the Jena developers.
Too focused? I don't understand this. I find it hard to imagine an
outcome in which making the internal structure of the project -
roadmaps, wishlist, etc - more central on the current site would make it
easier for current/new Jena users to use the documentation effectively.
Again, you seem to be advocating that we make the needs of the minority
a priority, and that's not making any sense to me.

> We can probably do something more/better to move users, from being
> users to be developers. 
Why should *we* move *them*? I'm quite happy for Jena to have more patch
writers and committers, but isn't that a choice for contributors to make
for themselves?

> This could also have the side effect of
> reducing support load for new users (since you have more developers
> who can do that if they want to) and new users might remain less
> time users.
That seems a very optimistic assumption.

>>> In less words, the website should be tuned at growing a community
>>> around Jena. Therefore, in my opinion, we need to think about those
>>> steps and movements and make it as easy as possible for everybody
>>> who might be interested.
>> Certainly these aims should be included. My advocacy is actually that
>> the *primary* aim of the documentation is to help users make effective
>> use of the toolkit. One measure of success, for me, would be that the
>> growth of the support load on jena-users is slower than the growth in
>> the number of downloads.
> Is the *primary* aim of the documentation == the *primary* aim of the
> Jena website?
Well, yes. Unless we have two websites in different places, one for
users and one for developers, but no-one's advocating that and I don't
think Apache would like it. I certainly don't see the need.

> If so, would it be correct to think that a website which only support
> Jena users is enough? For me, clearly, this would not be enough. ;-)
Oh for goodness sake. I have not, ever, suggested a site that *only*
supports our users. In my initial suggestions, I proposed that a key
constituency that we need to better support is Jena developers. I think
roadmaps, wishlists, etc, would be great things to add (maintaining them
is another issue of course).

> I am not sure I fully agree on the success metric as well. Number of
> downloads or decrease in the support load are not good enough for me.
"One measure of success" != "the only measure that we should consider"

> You can reduce your support cost to zero if you want. Can't you?
> We can increase number of downloads in many ways, having a huge number
> of newbies users who download Jena and simply gave up (with no support
> cost) will increase the number of downloads.
I am completely failing to understand this bit.

> Personally, I would prefer to look at number of bugs found by others
> (not Jena committers) or number of feature requests from others or
> number of patches 
yes, fine.

> or, why not?, doubling number of committers in
> one or two years. 
Fine, and that would get us to around 20 people. There have been 900
downloads of Jena just in the past 3 months, not counting installations
from maven.

> I am not saying, these should absolutely be the
> measure of success, but these seems to me more appealing (and ambitious)
> rather than downloads or support load on jena-users mailing list.
You're setting up a strawman argument that I didn't put forward.

> [snip] good suggestions on roadmaps etc

> Internships, Google Summer Of Code, or other similar activities should
> also be part of a list of possibilities to engage more with developers
> who might help us more and more (up to a point where they become
> committers).
Um, didn't you +1 the comment about not being too ambitious?

> To me, "helping users make effective use of the toolkit" is very important,
> but somehow 'limiting' and, hopefully, I explained why: it focuses on users
> only and not on their evolution, grow and engagement with the Jena
> community.
The fundamental problem I'm having with your argument is the implication
that supporting the (many) actual users better somehow precludes also
supporting the (relatively few) new committers. Not only is that not
what I've said, but it doesn't make any sense. However, I have a real
concern that making the *primary* focus of the outward-facing Jena
website be how to add patches and write code for Jena will definitely
deter and confuse potential users.


Ian Dickinson                   Epimorphics Ltd, Bristol, UK
cell: +44-7786-850536              landline: +44-1275-399069
Epimorphics Ltd.  is a limited company registered in England
(no. 7016688). Registered address: Court Lodge, 105 High St,
              Portishead, Bristol BS20 6PT, UK

View raw message