Ian Dickinson wrote:
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.
True, less people but an equally important minority.
However, so long we have a section named "Getting Involved" | "Community"
linked from the global navigation and well visible from the homepage I
am happy.
Do you or someone else have a strong argument against having a section
named "Getting Involved" | "Community" as last link in the global navigation?
As an aside, more patches = more work for committers to review; qv. the
current discussion around the query termination patch.
I am happy to increase that type of work, it takes time I admit, but it's
healthy and it potentially produces better quality software. For example,
I was very happy to see the patch on query termination and I bet everybody
running a public SPARQL endpoint based on ARQ/TDB are.
Many of us have came up with a patchy solution to provide that important
and missing functionality, the debate is a consequence of the diversity
and the fact that although this might seem a trivial feature to implement
it's not easy to get it right. We are getting there though.
So, although I agree that it can drain energy, the workload of reviewing
patches and discussions on JIRA is really welcome by me.
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.
Unless you have a strong argument against, I'd like to provide content
below the "Getting Involved" | "Community" section which provide instructions
on how to check out Jena and/or TDB, SDB, ARQ, ... sources, compile them,
open them in Eclipse, generate Maven artifacts, produce a patch properly,
etc.
Once, again, I got your point that developers are a minority. But, it's
a minority I want to cherish with two or three pages below the "Getting
Involved" section.
Look. The problem at the moment is that we have a lot of content on
openjena.org, 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.
I certainly don't want to degrade the situation.
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
again.
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.
Roadmap, Wishlist, etc. can go below the "Getting Involved" section and
they can come later. Is this "too" central?
No, not a priority, but let's keep the important minority of developers
and potential future developers in mind. The "Getting Involved" |
"Community" section is what I propose to do to serve their needs.
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?
Sure, but if they chose to do so I want to support them and help them
and provide them with the informations they need. I propose we do so in
the "Getting Involved" | "Community" section on the website.
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.
What's wrong in being optimistic? ;-)
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"
Yep.
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
fine
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?
An ambitious example for the "Getting Involved" section.
Not something we *must* do as a first pass or soon.
Which my +1 are you referring to?
I don't generally think it's a bad thing per-se to be ambitious or optimistic.
About the website: using simple tools and having an incremental approach
which allow us to make progress and migrate the existing content to the
new website quickly is something I fully support and I want to help with.
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.
I propose we have two sections to support users: "Getting Started" and
"Documentation". I suggest not to have more, it will probably confuse
people. But, I will not oppose if you decide you need more.
I propose we have one section to support developers and the growing
community of potential "contributors" to the project: "Getting Involved"
or "Community". I will propose content for the "Getting Involved" section
of the website on a separate thread.
Paolo
Ian
