BMLT Root Server Release 2.16.0
This release improves the way that meetings are entered, especially virtual and hybrid ones, and adds some error checking and other improvements.
To add a meeting or make changes to an existing one, the new interface has radio buttons to select the meeting venue type, as shown in the following screen shot. (This should avoid some common errors.) There is also some other error checking for meeting location and virtual meeting information. Existing meeting data will be OK as is — the error checking is done only when trying to save a new meeting or changes to an existing one.
There is also a change to the Formats pane in the meeting editor: it no longer lists the formats VM (virtual meeting), TC (temporarily closed facility), or HY (hybrid meeting), since those are now handled by the radio buttons instead. At the start of the pandemic, with numerous in-person meetings closing and online ones opening, using formats for this was the quickest way to adapt, but has proven error-prone. Underneath, the database is still using them for now for compatibility with crouton and bread; but the person editing meetings won’t see or use them.
That’s the basics. For those who want more details, the rest of this blog post describes the changes in more depth from several points of view:
- users of BMLT meeting data
- area and regional webservants who are maintaining meeting data
- root server admins
Users of BMLT Meeting Data
This part is easy: folks searching for meetings on a website or using a printable schedule won’t see any change at this time, although hopefully the meeting information should start being more consistently represented and presented.
Area and Regional Webservants
The principal change is that the meeting editor now has radio buttons to select the meeting venue type, as shown in the screenshot above. There is also some error checking. This comes in two flavors: errors and warnings. For errors, the system will insist that the error be fixed before the meeting changes can be saved. For warnings, there will be a warning, but users can go ahead and save anyway if they want.
This screenshot shows the result of trying to save a meeting with a bad URL in the Virtual Meeting Link field. This is treated as a hard error. There is an error message under the “save” button, and also in-place just below the Virtual Meeting Link field.
Next, here are a pair of screenshots showing the result of trying to save an in-person meeting with no street address. This just generates a warning. First, an alert pops up:
Then if the user hits “cancel”, they will be taken to the following screen, which shows the warning in yellow next to the Save button. On the Location tab they can also see the warning in place, underneath the problem field.
The system handles multiple errors and warnings correctly — the user is shown them all.
Internally, the software maps the venue type selection to the HY, TC, and VM formats as follows:
- in-person: none
- virtual: VM
- virtual (temporarily replaced an in-person): VM, TC
- hybrid (both In-Person and Virtual): HY
If a user tries to edit a meeting that had some other combination of these formats selected using the older version of the root server, the radio buttons for the venue type won’t have a type selected, and the user will need to select a type before saving changes.
Potential Issues
We hope that it will usually be clear which venue type to select. Here are two cases that might be problematic, along with suggested solutions.
- There might be a group that has decided to divide into two separate meetings, one in person and the other virtual, still meeting at the same time. One approach here is to duplicate the listing and have two meetings, one in person and one virtual. Alternately, if the group or webservant wants to avoid having two separate listings, mark this as a Hybrid meeting, and explain the particular way the meeting is run in the Comments field. Or there might be some other variation, for example, starting out as one meeting, and then splitting into two after the opening readings — explain this in the Comments field as well.
- Some areas are continuing to list temporarily closed meetings with no virtual replacement in their regular schedules. We recommend not doing this, since the closed meeting listing isn’t going to be useful for someone looking for a meeting. Instead, the meeting should be unpublished if it may someday come back; or just deleted altogether if not. Here is some background on the TC format: this format was added specifically for the pandemic. When the pandemic started, two types of virtual meetings popped up: those that replaced in-person meetings, and those that had never been tied to a physical location (pure virtual). TC was added for the former — by combining the TC and VM formats, you could communicate that “this is a virtual meeting, but it’s just replacing our normally physical in-person meetings until the world opens up again.” Pure virtual meetings were intended to use only the VM format. By that logic, TC was only intended to be a modifier to the VM format — not to be used on its own. That said, the need can still arise to note that a meeting is closed temporarily (for example, for repairs to its meeting place, for a holiday, etc) — this could be true even for a virtual meeting. Here we suggest either using the comments field or the “Closed Holidays” format if appropriate. Another option is to just prepend the meeting name with “Closed until [Date]” or the like — this makes the closure very obvious in the meeting list.
We welcome feedback about these and any of the other design choices in this release. If appropriate, please open an issue on GitHub to report problems or suggest enhancements.
Errors and Warnings
Here are all the (hard) errors that are currently checked for:
- no venue type selected
- a virtual or hybrid meeting, with none of Virtual Meeting Link, Phone Meeting Dial-in Number, or Virtual Meeting Additional Information filled in
- invalid URL in the Virtual Meeting Link field
Here are all the warnings:
- no location information filled in (minimally, there should be a city/town and state/province, or a zip/postal code)
- no street information for an in-person or hybrid meeting
- virtual or hybrid meeting with no Virtual Meeting Link or Phone Meeting Dial-in Number (just a warning for now though, since Virtual Meeting Additional Information might have enough information to join the meeting)
- virtual or hybrid meeting with a Virtual Meeting Link but nothing in the Virtual Meeting Additional Information field
We will likely add additional checks in future releases. For this release we were intentionally conservative about what to count as a hard error.
Root Server Admins
Format Changes
The principal change from the server admin viewpoint is that the VM, TC, and HY formats are special, since they are used to encode the choice of venue type. They are still listed on the Formats tab, since they are still visible in crouton and bread. However, unlike the other formats, they cannot be deleted. Further, the English versions of their keys are read-only, since that is how the software identifies them; and the corresponding NAWS Format and Format Type are read-only as well. The other fields can still be edited as usual, including the name, description, and keys for languages other than English. The following screenshot shows the Formats editor with the HY format at the top. Note that for HY there is no “Delete This Format” button, and the read-only fields are greyed out.
For server admins who have left the HY, TC, and VM formats alone as they come out-of-the-box, the new release should just work.
To handle cases where these formats have been changed, the new release includes migrations code to check and update them if needed, or add them back if they have been deleted. Server admins can just let the migrations code fix things up; or else can edit the formats by hand in advance of firing up the new release. As of the date of this release (April 3, 2021), the migrations code should handle all root servers currently registered with tally.bmlt.app.
Here are the checks and updates that the migration code performs. The code tries to find an existing format for HY, TC, or VM, as follows. It first checks for a version of the format with the correct English key (e.g., HY); if there isn’t one, it checks for a version of the format that maps to the corresponding NAWS format (e.g., HYBR); and if that doesn’t work, checks for a version with the key (e.g., HY) in some other language. If no luck with any of these, it makes a new format. In any case, it fills in the formats for all of the current languages if some languages are missing.
After installing the new release, server admins can verify that the formats are correct by selecting the “Formats” pane when logged in as serveradmin, and making sure that the HY, TC, and VM formats appear with the read-only fields greyed out and no “delete this format” button, as shown in the screen shot above. Also check some meetings that had some combination of the HY, TC, or VM formats selected before, and make sure they are showing up correctly.
After upgrading, server admins may want to check for occurrences of the WEB format (if used on your server), update those meetings to use the correct radio button, and remove WEB from their list of formats. After this is done, remove the WEB format altogether, since it should no longer be needed.
NAWS Exports
We expect that, as meetings are edited and entered, the quality of NAWS export data will gradually improve. One other change of note here: some meetings had large numbers of formats checked. NAWS export data is limited to 5 formats. Before, the root server was just selecting the first 5 (in alphabetical order), with the result that formats toward the end of the alphabet — in particular, the critical TC and VM formats — were getting dropped. Now, the root server exports the most important formats first, in particular HY, TC, and VM. The default is likely fine as is, but can be overridden with an optional variable $naws_export_formats_at_front in the file auto-config.inc.php.
