To be clear, it’s no more the website of anyone on these message boards than it is your website. We’re all a bunch of scouting volunteers/parents/youth trying to help one another sort out the issues various people run into. The BSA is not officially monitoring these forums, although there may incidentally be BSA staff among us, since many do more in scouting than just their official jobs. Venting at the folks here isn’t going to improve things.
There’s plenty of information about how the calendar module works in the help sections at help.scoutbook.com. It’s far from perfect, and there’s been plenty of discussion here about that, too.
There’s no national requirement that Scoutbook (scoutbook.com) be the calendar/messaging/etc application for every unit (or even any unit). There are lots of folks who still use other platforms for everything, and submit advancement via IA2 (scoutbook.scouting.org) or Scoutbook (but not both IA2 and Scoutbook, since that causes problems). Each unit has to make that call for itself, and I’m certainly not going to advocate that every unit jump onto Scoutbook. I’ve been using it since before the BSA purchased it, and as well as it has done some things, it’s always had some blind alleys. I try to remember the 5th, 6th, and 8th points of the Scout Law, and move along.
Generally, if I don’t invite someone to the event (irrespective of the calendaring software), I don’t expect them to automatically be able to see the event or get email reminders. Just because we got a new engineer at my office, I don’t expect him or her to show up on our group meeting invites without some action on my part. The issue with not having dynamic invitee/reminder lists is longstanding, and manifests in several different ways (new people not being added, people who have left not being removed, reminders going out to people who have RSVP’d “no”…).
There is plenty of information (in these forums and elsewhere) that there are ongoing development phases planned and underway. The BSA doesn’t share when anything will be “finished”, nor exactly what features will have been implemented when a particular development push completes. The calendar alone will require quite a lot of reworking to address various issues tied to it.
For example, just consider the difficulty of coding a dynamic invitee list. Code would have to be created to reflect the types of “groups” that are being created: unit (troop/pack/crew/ship), subunit (patrol, dens), specialty (PLC, unit committee, scoutmaster corps,…).
Now, once that’s coded, does the logic in the code work if the whole patrol transfers to a new patrol, and wants to keep its existing planned events (i.e. patrol name changes)? When I initially schedule and invite a group of people (say the PLC) to a meeting, and the people in that group changes (e.g. a new person gets added to the group and two people leave), how frequently does the software check for changes to the group? What implications does that have for computing overhead? Where’s the balance between making sure PeeWee Harris gets automatically added to the PLC meeting on Tuesday when he just got his new position added to his account Sunday evening (because that’s the first chance the leaders had to update the list) and burning all your computing cycles checking for new changes? Multiply that by however many units are out there (some of which aren’t using Scoutbook for calendaring at all, so it’s entirely wasted computing time), and the problems associated with architecting and implementing this beast begin to fall into perspective. For one unit using the software, the differences in computing time are probably negligibly impacting. For thousands of units, it starts to add up and impact other basic functionality. Is it doable? Almost certainly. What’s the trade-off with other needed functionality? I dunno, but nothing is free.
As a user, I get that we want the code to work exactly the way we expect it to out of the gate. As an engineer, who has done some programming (albeit nowhere near the level of what we’re talking about here), I recognize that all software is dynamically trying to achieve a state of “adequate” functionality, with the users and software owners consistently moving the goalposts on what constitutes “adequate”. Scoutbook isn’t that old as unit management/advancement tracking software goes. It’ll take some time to get to the point where the developers are mostly adding bells & whistles instead of wheels and brakes.