Brother-Tyler
commented
2 years ago Just addressing a few that I can speak to.
-
Going with David's recommendation of $1K annually. We also have to budget for license renewal every 6 months (amount will depend upon our features) plus periodic upgrades and what-not. We have funds to cover us for three years or so, but we'll also address fundraising issues outside of this effort (annual fundraisers, merchandise, possible monetization of certain features, etc.).
-
Would it help if we pre-convert some of the custom BBCode usage? For example, the various Resource topics and Tabulae all use custom BBCode. I could convert much of that to standardized BBCode now by manually editing. This would save us time later.
Follow on - should we notify our members of the impact on the custom BBCode? This would give those that care the opportunity to edit their posts to remove the custom BBCode, or at least give them advance notice that their formatted articles might lose their format (so that they don't freak out when it happens).
-
How much time do we need to road test the site with a larger crew? How large of a crew do we need? While we want to complete this as soon as possible and with the minimum crew possible, we don't want to skimp on either time or manpower in a way that will deliver a substandard result. Are you looking at a testing period (for the larger crew) of days? Weeks? Months? I know that we won't have a definite answer now and that much will depend upon the type, quantity, and resolution of any bugs we might discover, but I'm trying to get a rough time period for the purposes of planning/milestones.
-
I see this as a possible long pole. I'll have to start working on crafting a lot of the low-end help files (e.g., discussion post style tutorials) now. The key, I think, will be identifying the tutorials that we want, then prioritizing them. I was working on the BBCode 101 for the legacy site, but I'm pretty sure that I'll have to switch focus over to the BBCode 101 for the new site.
Assuming our budget works with the available options, I think that we can decide upon the HW relatively quickly (by the end of this week). With that done, we can initiate the deal-brokering with the company and figure out their schedule requirements/limitations. Once we confirm with Kurgan that the UX is done, we can expand the testing team to give us time to identify and fix any problems. In the meantime, I'll work on the help files/tutorials.
Assumption is that our initial migration will include legacy capabilities, with release of additional capabilities taking place incrementally as we get each up and running. We'll just need to establish our prioritization of those additional capabilities. There will also be background discussion with the mod/admin team on how these capabilities will be used by the community (which will probably affect some of our development/testing).
Note that the mod/admin team has been discussing some structure (category/forum) changes. I've already begun preparing for those changes, but I plan to hold off on actual implementation until we perform this migration. I'll probably turn the changes on right before we shut the site down for the migration. I don't expect these to affect us in any significant way, but they will create a slight learning curve. What I'm basically looking at doing is having a single period where we shut the legacy site down. I'll activate all of the structure changes at that time (Day 1). We'll then use that version of the site for our efforts (Day 2+). When the new site comes back online, it will be under the new software, UX, and structure. All of the work involved in the structure change is on me.
sibomots
KurgantheLurker
The issues contained in the backlog prescribe the gotta-have next steps.
Budget numbers for ISP to host the system. Assume dedicated HW, 2 year term, from major 100 Mbps backbone, etc.. (think: OVH, etc.)
Scour the UX for all the effects that put on par the beta site with the legacy site.
Ascertain the new UX for the new UX features NOT in the legacy site (Blog and Article) -- Look and feel, plus the "rules of the road" -- how/when/where will users be able to use those two new features not in legacy site.
We're going to hand-convert (via SQL) all custom "BB code" that was used (and defined by) B&C. But in the beta-site, no custom BB code is honored. A user types in [some_code] and if that code is not evergreen boiler plate BBcode, it won't be parsed. For all records in legacy database that contain literal B&C defined codes, those will be converted via SQL in place in the DB for the correct CSS/HTML stanzas they represent. That is already a known technique.. It's on the backlog.
For the in-site editor, we're going to table (shelve) for now any work to add the icons for the in-site editor that provide the capability to format content per the B&C "custom" BBcodes. Leave that for some other time, not on launch of beta.
Bug-bash on the beta site -- looking for all tweaks/defects/issues that pertain to missing UX collateral. Needs eyeballs. Recruit the mod+. Avoid self-inflicted myopia on what is or is not defect of UX.
The rest of it is more or less system level stuff. Preparing the machine, installing software and so on.
The user-experience of the casual user to B&C will be enhanced if all of the "Ask-Tell-Help" issues are resolved. How-to on the new features and any new sea-change rules or policies -- this is the time to make those changes during the scenery change of the site from legacy to beta to current.
Timeline:
I want to get to step 7 by the end of May. I want to make the month of June the month of down-time for the upgrade to happen.
Work back from June 30 for all schedule impact.