On Mon, 7 Jan 2019 at 16:05, Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > On Mon, Jan 7, 2019 at 3:41 PM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > > > > I recognize that this is non-trivial, and it's possible that it's easier to > > just let some things sit where they are. But a lot of those normally > > low-maintenance things are tech-debt time bombs. Or, they're really > > languishing. > > > > It'd be better if it was easier for more people to participate. We > have a lot of infra-types. It's kind of amazing in a bad way that > despite all that, we don't really have an easy way for more people to > help on that side. > This is where we run into the 'screwed before' setting in infrastructure. Most people coming in expect that they will have root on all systems right away. The problem is that multiple instances these people have also uploaded their private ssh keys to public places, had passwords like 'youcantguessthis1', reverse ssh shells for easy debugging in production, and similar things which they had done for years and don't see why we should be such sticklers on not letting them do it here. And when it blows up.. they are gone and other people spend a couple of 96 hour days fixing things. All of which usually gets followed by "we should never let this happen again", various processes and gates to slow down a future problem... years later people forget the 96 hour days thing and just feel those processes are a problem. I am not saying our processes aren't in need of improvement, but they need to be redesigned from a point of view of being sustainable, reliable and a limited resource budget. [Several of the ones that would be more agile usually require us to have 10x the number of systems we currently have as you do multi-site A-B testing and such.] > > > > > >2. Which applications > > > > have industry-standard open source or proprietary alternatives that we > > > > could move to. > > > I'm not coming up with too long a list here. Most of our apps are highly > > > specialised for distro making, but: > > > > > > * fedocal (which we pretty much spend no time on) > > > > Yeah, this'd be a good candidate. It was a great, useful tool for its time > > but is rather dated. It could use a *lot* of development work, and > > realistically, we all know it's not going to get it. > > > > Are there any nice open source calendar/meeting assignment web apps > out there we could deploy? I feel like this is a common enough venture > that someone has done something... > The reason fedocal was written was pretty much every other calendar/meeting is written just well enough to work for whatever project the writer wanted. After that calendaring gets 'hard' and you end up with no one putting in that '10% (aka 90%)' that is needed because it costs a lot of time and effort and little reason because you fixed the itch already. I last looked in 2016 but fedocal at that time met our itches better while all the others would require lots of add-on work. -- Stephen J Smoogen. _______________________________________________ council-discuss mailing list -- council-discuss@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to council-discuss-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/council-discuss@xxxxxxxxxxxxxxxxxxxxxxx
