[sakai2-tcc] Infrastructure discussion for future meeting?

[Steve Swinsburg]

+1 sounds good. Lets get a list of issues that are feasible to address in
the timeframe, then we can vote for one.

cheers,
Steve


On Wed, Mar 13, 2013 at 3:30 PM, David Adams <da1 at vt.edu> wrote:

> 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
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130313/34a5873f/attachment-0001.html