[sakai2-tcc] Infrastructure discussion for future meeting?

[John Bush]

+1 I like this approach.  Its actionable, clear, keeps us focused and
moving forward, and stops us from squabbling over things that are too
far out to be actionable.

On Tue, Mar 12, 2013 at 9:40 PM, Steve Swinsburg
<steve.swinsburg at gmail.com> wrote:
> +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
>
>
>
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>



--
John Bush
602-490-0470