[sakai2-tcc] Infrastructure discussion for future meeting?

[David Adams]

Steve Swinsburg wrote:
> Dave talked about running a list of issues past management to get
> their approval for resourcing and funding.

I'm doing a poor job of communicating, so I apologize. But running a
list of issues past anyone is the opposite of what I think should
happen. The TCC should pick one problem. Then solve it.

The community looks to the TCC to lead the way. The TCC understands
better than most anyone what the core internal issues are with the
Sakai architecture. My list of 20+ pain points is not something to
be presented to anyone. It's just a demonstration that we don't need
to go fishing for ideas.

Here's what I've been trying to propose, cleaned up a bit now that
I've thought it through some more:

Day One: The TCC votes to choose ONE, a SINGLE problem to fix before
the conference. Something that will address long term technical debt,
that will improve Sakai for its users, its deployers, and its
maintainers, and something that is doable by a small team on a short
time frame.

Day Two: The TCC announces the project, its coordinator (a TCC member
with technical expertise in the area), the start date, the timeline,
and asks for specific human resources.

The project coordinator would need to set up meetings and whatever
workspaces are needed, choose the team, acquire whatever access is
needed for the members and get the planning started and serve as
mentor and leader to the team and most importantly to keep them on
task. No project creep.

That's it. Pick one problem, then solve it.

Myself, I don't have the expertise, or honestly the temperament, to
lead any such effort, but I'll volunteer to be the sys/ops contributor
on the team, whatever the project turns out to be. I'm not a
developer, but I'm Java-capable, I can troubleshoot with the best of
them, and I have 14 years of strong feelings about deployment,
configuration, manageability, and logging. I will also do my darndest
to convince my management to commit serious Java developer time to the
project as well. If I can pull that off, that's two.

How many other schools have staffs of developers actively working on
their own local tweaks, but not contributing significantly back to the
community? I'll bet there are many like Virginia Tech who would like
to contribute more directly but don't see a safe way to do so. Just
look at the msub tree in source.sakaiproject.org. And that's only a
fraction of the schools who have their own developers that could be
working for the community as well as for their employer.

We have lots of big schools new to Sakai who I'd imagine would love to
contribute if there were an easy way to jump on board. But trying to
do something from scratch without some backup from the TCC and without
a technical lead/mentor to ensure things go the right way is too big
of a risk. We have programmer's cafe etc for people who want to write
new tools, but new tools don't have any risk of blowing up the entire
application. Lots of people out there know how to program for Sakai,
but how does one make the leap from tool writing to contributing to
serious improvement of the core of Sakai? That's the hump we need to
help people get over to shake loose Chuck's hypotheticals.

> How do we get that list of stuff to fix though, do we just make
> a list and vote on it? Pick one and go from there? Should we
> have some overall goal/direction for the product to be working
> towards for the next few years?

I don't think there should be an attempt to make a comprehensive
list, nor a long term timeline until this process picks up steam.
All this listmaking and planning and data-gathering are a huge
distraction at this stage. The community needs leadership and
focus: Pick one problem, and then solve it.

It doesn't have to be the biggest problem, or the "highest priority".
The TCC is implicitly entrusted to make those determinations for the
community.  If you ask, you'll get a thousand opinions. Don't ask, just
pick one problem, and solve it. You'll get plenty of feedback about
what you *should* have chosen, set that aside until you're done with
fixing the problem.

If this idea works, and progress starts being made, then you can start
asking for input. But in the doldrums we're in now, what's needed is
action. Pick one problem, and solve it. Only then should we ask "what's
next"?

> I think all of that is an important discussion to be had so that we
> don't waste effort in one area that may later be made redundant. For
> example fixing or upgrading, JSF tools, if we later decide to drop
> JSF completely (for example, totally hypothetical, not be used in
> any argument).

That's a risk we've got to be willing to take. But don't spend time
thinking about it. Skip the problems with thorny questions and side
effects for now. But pick one problem, and solve it.

-dave