Posted by Fleet Captain Adam W. (Current Ruler of the Club) in TECH Report

Posted by Admiral Joe P (Librarian / TECH Chairman) in TECH Report
Hello Everyone,

The TECH report that was requested for the end of January is presented below. We will be more than happy to answer any questions you have about it.

Joe P,
TECH Chairman

---

This report is to be split up into two broad sections.

1. What TECH has done since our last report in July 2018
2. What TECH is doing now and has on the agenda for the next 6-12 months

The Last 8 Months

The TECH tracker has logged 135 issues, of which 2 were deleted, 12 remain open and the remaining 121 were resolved. Of the 12 remaining tickets all but 1 are Exodus feature requests and suggestions, which following this report will be closed out.

Of the 121 resolved tickets, two distinct categories of issues were reported. Exodus bugs, which have steadily been fixed in various hotfixes, and user experience issues, with TECH fixing up learning curve mistakes or toggling the access to admin section button. Category two requests have over time dramatically decreased as expected.

Exodus has advanced from version 1.0.0 to version 1.5.1, with each new minor version releasing a new feature set or “module” plus a butt tonne of bug fixes and optimisations. The five modules released were :- General Election Polls, Time zones, Academy Graduations, Statistics and EGO elections.

Other major events have been the issues surrounding our hosting provider which in January migrated from ServInt to LeaseWeb. Specifically the two major outages in January and February.

That’s a basic summation of the last eight months.

The president has asked us to provide a comparison of what we announced in the last TECH post which was released just after the Exodus Migration (https://www.star-fleet.com/core/command/command/notes/1301/) with what we actually ended up doing. The priority list was thus:

• Presidential Election Voting (we needed this in two weeks)
• Academy Graduation Form (it was provided by Drupal)
• X-Fleet Application Form (same as above)
• Amanda Noon Archive and other GM Department applications (we didn’t know this was Drupal-dependent; it is broken as a result)
• Personnel Department applications not already covered in the core Exodus functionality (Some of this was Drupal dependent and broke)
• WeBBSpace Archive
• The Library
• EGO Election Voting
• Anything we need for Awards
• Edict Archive replacement (we’ll still update the old one until the new one is in place)
• Academy departmental application (it’s the lowest priority because it actually works pretty well)

Out of this list, the following items are fully complete:

• Presidential Election Voting
• Academy Graduation Form
• Personnel Department applications not already covered in the core Exodus functionality
• EGO Election Voting

We also added the following additional major features that were not on our original roadmap :

• Membership Statistics
• Tools to replace Personnel Department Google Documents

These items have had some progress, but are not complete yet:

• Awards Functionality: We have everything but the nomination form complete, and plan to release this after the election is over
• The Library: The software was done a long time ago and a good portion of the data migration has been accomplished but the graphic design is now dated and could use some work to bring it inline with the current visual template and organisational schema. However this is incredibly low priority.

We have not yet started work on these items:

• Amanda Noon Archive and other GM Department applications: This will be the next highest priority work and is expected to start after the Election is complete
• X-Fleet Application Form: Only one person has asked since the migration where this is, so its priority has dropped a bit.
• WeBBSpace Archive: We plan to start this after we are done with the GM Department’s needs, though we know many people are waiting patiently for it.
• Edict Archive replacement
• Academy Departmental Application: This is still the lowest priority because it works mostly well

These additional major features have also been added to our list:

• Features for the CMM: This includes new features to support the management of a newsletter that is planned by the CMM in the near future.
• Replacement of the Issue Tracker: Just for the sake of purity we’d like something not PHP based and maybe a little more integrated with the site

As was stated previously, we use these priorities to determine what work we are going to do next at any given moment:

1. We will always prioritize fixing bugs over everything else.
2. If there are easy improvements to features we already have implemented, we will do those next.
3. If there are features we had on the old site that we don’t have on the new site, we will do those before any other new features.
4. If there is a legacy system that we can replace to noticeably improve people’s lives, we’ll do that next (like, the GM Archive)
5. If we don’t have any work that fits in the four categories above, we will consider doing totally new features the club has never seen before.

Just as a note, features such as portraits for characters would fall under category 5.

What’s next for TECH?

We’re currently working on two major projects.

1. Continued Exodus development
2. Phase 1 of Migrating to a more stable hosting provider

We expect Exodus 1.6.0 to be ready for deployment sometime in the next 1-2 months. Phase 1 of the Migration is about setting up redundancies to protect the club from catastrophic failure by our provider.

It involves:

• Updating our backup systems to be exodus compliant
• Setup and maintaince of an off-server cloud storage backup account
• Sorting and archiving current on-server backups

Phase 2 will consist of selection of a new hosting provider, finalisation and configuration of the server environment and it’s management tools. Which will then be followed by Phase 3

Phase 3 will consist of loading the most recent backup of Exodus into the new server environment, and dealing with any hiccups resulting from the new server configuration. Once everything is fine then the switch over takes place. During which time the site could be unavailable for a 24 hour period for some users.

Finally, in an effort to be more transparent and decrease the reporting burden with regards to future Exodus releases, we are internally discussing the possibility of making a publicly available roadmap of future Exodus development. It may take the form of a Kanban board that is kept up to date with current progress of our objectives, and is intended to reduce the need for additional reports in the future, as there would be a snapshot at any given time of what our progress on all fronts would be. This idea is still undergoing discussion as consensus has not yet been reached on whether such a reporting scheme is actually necessary and would reduce work.

Thanks TECH. This report gives me a better understanding of where we’re at and where we’re headed, and I believe the next President and the rest of the membership will think likewise.

You are welcome.

Am I right in thinking Membership Statistics isn’t quite ready for any site user to click on? Or maybe it wasn’t envisioned to be something just anyone would view.

Adam W.

Right on both counts.

It’s something that is very difficult to test properly before deploying, because we don’t have as much data available on our development machines to try it out, and because some of the behavior is database dependent (we use MySQL on the server, but usually use SQLite3 when developing). So, it’s hard to get it ready for ordinary users to actually use in the same way we can test and improve most other features.

It’s also not necessarily intended for ordinary users to use it, because some operations are very computationally expensive and would slow the site down if we let anybody do everything anytime they wanted. For instance, the button that collects data is itself only visible if you are a super user (e.g. TECH member) because it executes a query that fetches every single post for the previous 30 days, and does that for every day we don’t already have membership measurements. That query can take 2 to 3 seconds each time it’s run, and if we haven’t done it for a month, we run it 30 times. 3 seconds x 30 days = 90 seconds where everything on the entire site might go really, really slow until we get the answer. That’s not ideal.

Joe