Here's the body of an email that some of you will see on sakai-dev; I tried to provide a few ideas on how to include the bigger picture when making technology decisions, as well as some suggestions with respect to a community roadmap and supporting process:

=========

Hey, All:

I've been following this thread with great interest because I think that
how decisions like these play out speaks volumes about how our community
operates to those that are evaluating Sakai.

I wonder if the community thinks that we are at a point where we would
benefit from coming up with a general roadmap that outlines our next 2
or 3 planned releases, with priorities categorized in a few different
ways (by priorities, by school, by amount of work, by dependency) etc,
so that decisions such as this one can be made in a larger context.

For example, is a consistent UI (labels, icons, widgets) more important
to the greater Sakai community (or those considering adopting Sakai)
than Spring 2.0? Or is an improved installation process more important?
Or a portal interface? Or is there a new tool that we should get started
on to avoid slipping too far behind the other players in this field? Or
is there a category of errors that Alan has pointed out that the
community can agree should be cleaned up (at last)? Or is getting a
MSSQL version more important? Or is changing how groups/roles/perms
work? Or is "making Sakai easier to use" more important? Or is enabling
tool writing for new developers? Or is...?

Now, before Dr. Chuck reminds us that herding volunteers is like herding
cats, or that school A's local priorities may be different than school
B's local priorities, a community roadmap tells us where the community
is going. It is only as detailed as the community can agree on. So if we
can only set the expected release dates, well that's a great start and
well worth putting up for the world to see.

However, maybe the UI group could agree on a few goals. Maybe the QA
group would set a couple of goals wrt automated testing. Maybe the
developers would generally agree that they *should* prioritize Spring
2.0 ahead of a consistent view technology (or fixing bugs or eliminating
empty catch blocks or adding descriptive error messages or whatever).
Maybe the advocacy group would set a goal to adopt some sort of
documentation standards because, hypothetically, that's a weakness
they're hearing about.

After these groups did their work, we would see whether the UI Group's
goals and QA team's goals were consistent with the developers' goals, or
whether we would need to discuss a compromise: do X first to help group
A, then do Y to help group B. Maybe the advocacy group would ask
everyone to do a "Spring clean up" of Confluence because that's what the
people out there that sign cheques would appreciate. Really, we can't
know without going through the process.

While this sometimes feels like a pretty large community, I suspect that
the number of "core" developers is actually quite lean relative to the
size of this undertaking. And most (all?) of the developers already seem
to be busy with their "primary" or "non-negotiable" or "locally-driven"
projects.

A decision like upgrading Spring adds work, sooner or later, for not
one, but most or all of those same developers; it is this "add-on" or
"negotiable" or "community" work that I think the community may consider
trying to coordinate first, since it really does affect us all.

To rephrase: I'm not saying that developers shouldn't have input into
when technologies should be upgraded or switched, I'm simply saying that
our needs/wishes/desires as programmers need to be balanced with other
community needs for the community to thrive.... And if the community
thrives, it will keep providing us with ongoing (mostly fun!)
development work.

Here are a few examples of "non-technical" needs that the community
could, I believe, start thinking about (in no particular order):

1. how does a given decision affect pedagogical needs?
2. how does a given decision affect community building needs?
3. how does a given decision affect the ability for the community to
support our own software?
4. how does a given decision affect the ability for any given member to
support/upgrade/train locally?
5. how does a given decision affect our help modules, technical
documentation or qa processes?

And if we feel like most of our technical decisions are not affecting
these, why not? Are we simply not thinking about or listening to who
we're writing this for?

Of course, the questions that follow these are of the form "What
pedagogical goals are we trying to meet?" followed immediately by "Who
are the correct stakeholders to decide what our pedagogical goals should
be?" followed immediately by "How do we engage those stakeholders now
that we have identified them in our member organizations or in the
community?" followed, finally, by "Hey, does anyone know about any great
collaborative software we could use to help a few formal/informal/adhoc
groups do their work if we ask their help and create a reasonable,
finite, and doable mandate for them?" :)

Finally, I just wanted to mention that, as the current 2.1.x Release
Manager, I am pretty sure that nearly every decision between now and
June, whether technical, UI, or otherwise, will have an impact on how
easy the 2.1.x -> (presumably) 2.4 migration goes for 12 or so active
and contributing members of the community. (And, of course, the 2.2 and
2.3 migrations as well).

I would simply ask the early technology adopters in our community to
please remember that the faster the front of the parade moves away from
the back of the parade, the harder it is for the back of the parade to
catch up. In this case that means how difficult it will be to learn the
details of the new or upgraded technologies, the overall system
features, to reskin, to migrate local data, to train local users etc.
etc. etc. next June/July/August.

Which is, of course, just another factor to bear in mind when planning....

Thanks,

Brian