[sakai2-tcc] Infrastructure discussion for future meeting?

[Adrian Fish]

Very well put. Mentoring of stakeholder institutional developer resource in
line with clear TCC endorsed goals makes marvellous sense.

Adrian.


On 12 March 2013 15:08, David Adams <da1 at vt.edu> wrote:

> Agreed, JSF belongs on the comprehensive list. Make it #23, or include
> it under #2. My main point was that we could keep listing these items
> forever, and we can argue about how they're ranked or what else
> belongs. But none are going to get fixed until someone either a lot of
> resources or some level of community leadership takes the lead. No one
> has "a lot of resources". So the TCC's leadership position is all
> we've got.
>
> I firmly believe that if there were specific, clearly defined
> improvements proposed to be tackled in discrete projects led by expert
> TCC members, it would be a lot easier to recruit resources from the
> community. I feel certain that if I told my boss and our dev manager
> that there was a project underway to fix something like the back
> button and tab issues in even just a single tool, they would support
> giving over some, and perhaps a lot, of our local developers' time. But
> so long as there's no leadership from the technical experts, it will
> never happen. The *last* thing management would be willing to do would
> be to dedicate 500 hours of developer time to a locally-spearheaded
> improvement that might not make it into the next release, or any release.
>
> -dave
>
> David Horwitz wrote:
> > If your going to include RSF on that list you got to have:
> >
> > 21) A widely used display tech (JSF 1) that is both unmaintaned and
> known to kill app servers
> >
> >
> > D
> >
> >
> > On Tue, 2013-03-12 at 09:38 -0500, David Adams wrote:
> >
> > Steve Swinsburg wrote:
> > > How can one figure out what resources need to be applied and what
> > > areas need attention if you don't know the issues?
> >
> > Surely anyone reading this list could come up with a list of 20 high
> > priority items that need to be addressed in the CLE, without needing a
> > formal review.
> >
> > How about:
> >
> > 1. Confusing build/deploy process that I don't believe anyone in this
> >    community fully understands.
> >
> > 2. Wildly outdated support libraries (thanks Noah for tackling this one).
> >
> > 3. Failure to support basic browser features such as tabs and the back
> button.
> >
> > 4. Non-normalized, unsearchable data in core tools such as Content.
> >
> > 5. Lack of support for database failover except through driver
> indirection.
> >
> > 6. Poor or non-existent logging of basic processes.
> >
> > 7. Users are bound to a single app server, making zero-downtime
> maintenance
> >    and high-availability very difficult to achieve.
> >
> > 8. An authz system that scales poorly and is near impossible to maintain.
> >
> > 9. An API tightly bound to the particulars of the portal/portlet
> presentation.
> >
> > 10. Outstanding security issues in both unmaintained and brand new core
> tools.
> >
> > 11. Runaway database activity in most hibernate-based tools.
> >
> > 12. Serious lack of anything beyond the most basic administrative tools.
> >
> > 13. No support for a departmental tech support or junior administrator
> role.
> >
> > 14. Complete lack of inter-tool database relationships, sometimes even a
> >     lack of anything that could even be *used* as a pseudo-foreign key.
> >
> > 15. Lack of an asynchronous request system for long-running processes.
> >
> > 16. Incomplete and inconsistent archive/restore support.
> >
> > 17. RSF.
> >
> > 18. No clear separation between core functionality and toolset.
> >
> > 19. No registration of allowed property values by tools.
> >
> > 20. Two configuration systems munged together: properties and Spring.
> >
> > 21. A site management tool that's confusing and overwhelming, both to
> >     end-users and to developers who might want to clean it up.
> >
> > 22. A source code base that's full of redundant and inoperative code
> >     not to mention transition steps from half a dozen versions ago that
> >     still run at every startup.
> >
> > Oh wait, I said just 20.
> >
> > The last thing we need is for the best technical minds in the
> > community who understand Sakai's internals better than anyone else to
> > be spending their time running process audits and surveys to make a
> > carefully prioritized list of action items complete with work
> > estimates, full community input, and committee approval.
> >
> > >From the outside, what I'd love to see is a short list of clearly and
> > narrowly defined improvement projects (pick one or two from my list)
> > that would benefit everyone who runs Sakai to take on for the next
> > version that I can take to my management and say: "Here's something
> > we've been griping about for years, and the TCC wants to fix it. Can
> > we commit some of our personnel to assisting with the effort?" Without
> > a clear project to put them on, it's nearly impossible to get any
> > traction with the decisionmakers.
> >
> > What's chosen doesn't have to be vetted by multiple layers of decision
> > makers and processed through focus groups or ranked against a list of
> > alternatives. You guys know where the problems are, I hope. But none
> > of these things can be fixed without focus. The TCC needs to pick
> > something broken and take the lead to fix it. Then move on to the next
> > thing. That's the only way Sakai will truly improve.
> >
> > -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/20130312/421cd3fc/attachment.html