What would it take to remove the calendar?

[OCJ]

I think some people (Kindred as well) suggested in a calendar thread that the team needed to reduce the code base to something more manageable - so the resources available could keep it maintained. If that's the case it sounds like it will end up collecting dust in the corner.
Hopefully, if it's just that SMF is to become more modular, then the calendar will be maintained by someone?

Maybe the thread title is a wee bit misleading " ... remove the calendar".



Its a pity that there was so much squabbling over the future of SMF. Isn't there a democratic way of  getting end users needs and developers ideas voted on. At least it goes through a process that way so might not attract as much strong feeling when things dont go their way.

Developers decide on the best/top improvements that end users voted for. Maybe even a dedicated developers set of ideas.
At the moment it seems like the unhappy ones (forks) have divided and conquered themselves. The mods community anyway looked more active  say 4 years ago.

[青山 素子]

I think some people (Kindred as well) suggested in a calendar thread that the team needed to reduce the code base to something more manageable - so the resources available could keep it maintained. If that's the case it sounds like it will end up collecting dust in the corner.

You've got to think about modularity. Basically, the core codebase is very large from a lot of features. By making the features modular, you can (hopefully) increase security by thinking more about the coupling and interaction between the now-distinct pieces. Also, it means that security issues will be more compartmentalized. Issues in the calendar module would only necessitate an update of that module, not the whole SMF package.

Also, if done right, it means that the whole is actually more manageable than if everything was kept tangled together. Since you will have to enforce strict boundaries you only have to worry about the inner workings and how to implement those. Less side effects will occur. Overall, this means it's easier to manage the large codebase.

Hopefully, if it's just that SMF is to become more modular, then the calendar will be maintained by someone?

See above in that by breaking things into distinct pieces, it actually becomes easier to deal with all the code. This assumes that this modularity is done properly and maintained.

The mods community anyway looked more active  say 4 years ago.

At least part of that is due to the very long 2.0 development cycle causing those modification developers to lose interest or just become frustrated and leave.

[Arantor]

It's not really misleading. It was simply 'if the calendar were to be removed from the core distribution, how much effort is required'. The answer is... about a day's worth of effort if you know the code base, and the source of this post was to highlight the fact that it is doable and provides some insight on where to start to do so, because it's already been done.

Its a pity that there was so much squabbling over the future of SMF. Isn't there a democratic way of  getting end users needs and developers ideas voted on.

Without wanting to get political, my view is that democracy in software development doesn't work because you have more people involved in the decision making process than the people who actually have to make the decision happen, and that the best approach is for benevolent dictators to ask for feedback, then go away and implement it, much as XenForo is doing in terms of how they approach development.

I would be very biased if I were to dwell on the squabbling, as one of those directly involved. There was a time when I nearly ended up on the dev team, but in hindsight, I'm very glad that didn't happen.

At least it goes through a process that way so might not attract as much strong feeling when things dont go their way.

That's the problem with democracy, you get so many more voices that you can't hear when something important is being said, and it has a habit of sucking all the productivity out of things.

Developers decide on the best/top improvements that end users voted for. Maybe even a dedicated developers set of ideas.
At the moment it seems like the unhappy ones (forks) have divided and conquered themselves. The mods community anyway looked more active  say 4 years ago.

There's a reason why there's only two properly active forks at this time when at one point there were about 8.

[Angelina Belle]

Actually, this thread started in the forks discussion board. It was a good fit there. It was moved here because many team members would prefer not to devote too much space to a fork with a restrictive license (somewhat like the one the SMF team struggled so hard to move away from in the last couple of years).

The difficulties the Wedge team had extricating the calendar functions is an object lesson on what happens when a nice little forum software like SMF grows organically.
The Wedge fork team was frequently confounded by knock-on effects of removing calendar functionality, and errors in places they would not have expected them as a result.
This is because so many features of SMF are so intertwined.

So I thought it was a pretty interesting read.
The idea is to build the next SMF with the basic idea that different functions are actually separable things, not all mushed together like a plate of stoemp.
Not that there is anything wrong with a plate of stoemp. Especially with an egg on top.

But you can imagine it would be difficult to improve the carrots after they've already been mashed in with the potatoes.
It's part of the evolution of SMF.

[.Vapor]

It would be nice to add an option to "enable" and "disable" the calendar. Some of us do not use it...in the first place.

[青山 素子]

It would be nice to add an option to "enable" and "disable" the calendar. Some of us do not use it...in the first place.

You can disable the calendar functionality already. This topic is about removing the actual code from the software.

[kat]

* K@ watches the Spamtard...