WMIRS 2.0 Rollout Plan?

[Fubar]

All of this could have been done far more securely and efficiently by simply providing an API to transfer data to WMIRS.  Existing systems are out there that do all of that and light-years more, but NHQ didn't invent them so they must be crushed.

I'm not sure each wing having their own system is a better way.

[JeffDG]

All of this could have been done far more securely and efficiently by simply providing an API to transfer data to WMIRS.  Existing systems are out there that do all of that and light-years more, but NHQ didn't invent them so they must be crushed.

I'm not sure each wing having their own system is a better way.

A few points:
1)  There are 3 or 4 systems right now out there, not one for each wing
2)  The good systems will spread, the poor ones will die, the good ones will likely merge organically as some will do some things really well, while others will do other things really well
3)  They all have significantly more capability than WMIRS No. 2
4)  Each system has spent more volunteer time chasing ever changing, and I submit intentional changes for the purpose of disrupting, interfaces with WMIRS, than they have on actual performance improvement over the last several years

If that time sunk down the black hole in #4 above had been free to improve systemes, we'd have some great capabilities that were widely distributed already.

The simple fact is, one-size does not necessarily fit all.  IMU is fantastic, for example, when you have a big mission with a lot of staff working on different things that needs to be integrated into a larger picture.  On smaller missions, however, the overhead consumes the benefits and it becomes a net-hindrance.

The point of an API to transfer data is that you could build a "Light" version of IMU that dealt with the "small" missions pretty quickly and easily.  We've got a guy on here who does iOS stuff, and he could probably crank out a mission management package that would run on an iPad in no-time if he had the interface to upload the data to WMIRS securely.  Me, I'd love to take the time to adapt the "Search Manager" application that you go through in the Inland SAR Planner's Course into a mission management platform...

However, NHQ will spend their contrained resources on blocking any attempt at that because they didn't invent it.

A couple of years ago I worked up a spec for an API, and all it really needs is 7 functions:

• Authenticate User
• Read Sortie Data
• Read Report Data*
• Create Sortie
• Delete Sortie*
• Modify Sortie Data
• Release Sortie**

* Optional but nice to have
** They may want to retain "Flight Release" as in-interface only, in which case this would not be needed.

Those functions, along with an XML data schema (so a field name for "Starting Tach" for example), and building an app to do things would be childs-play.

[JeffDG]

they are resource constrained.

Maybe, but there's no excuse for that whatsoever.

If outside contractors are doing this, then it's arguably FWA.  This should be an in-house project with members
from all over the country, and when resources are "constrained", bring in more.

At some point, it may come to the point that a submission to CAP-USAF/IG to that effect may be necessary.  I'm coming to the opinion that we need to include volunteer man-hours in the definition of "waste" for the purpose of FWA.

[RiverAux]

they are resource constrained.

Maybe, but there's no excuse for that whatsoever.

If outside contractors are doing this, then it's arguably FWA.  This should be an in-house project with members
from all over the country, and when resources are "constrained", bring in more.

At some point, it may come to the point that a submission to CAP-USAF/IG to that effect may be necessary.  I'm coming to the opinion that we need to include volunteer man-hours in the definition of "waste" for the purpose of FWA.

Are you kidding?  The military would probably consider this a fine example of a well managed inexpensive software rollout.  FWA is ludicrous. 

[JeffDG]

they are resource constrained.

Maybe, but there's no excuse for that whatsoever.

If outside contractors are doing this, then it's arguably FWA.  This should be an in-house project with members
from all over the country, and when resources are "constrained", bring in more.

At some point, it may come to the point that a submission to CAP-USAF/IG to that effect may be necessary.  I'm coming to the opinion that we need to include volunteer man-hours in the definition of "waste" for the purpose of FWA.

Are you kidding?  The military would probably consider this a fine example of a well managed inexpensive software rollout.  FWA is ludicrous.

If wasting volunteer time is considered a good thing, then NHQ should be swimming in medals.

[Eclipse]

Are you kidding?  The military would probably consider this a fine example of a well managed inexpensive software rollout.  FWA is ludicrous.

It's really not.  Just because the military is comfortable buying a new car when there is a flat tire, doesn't mean
CAP can afford the same attitude.

CAP purports 60,000 members, approximately 1/2 of which are adults (another area reality is somewhat "challenged".

Of those 30k, a significant number are IT professionals with direct and relevent experience and skill regarding these
types of systems, yet do you know of any public call for assistance in this regard?  Or is all being farmed out to
contractors (I don't know, but it should not be a secret).

If you do these kinds of things in-house for "free" and they have warts, no harm, it's free.

If you do these kinds of things using paid contractors and they work as promised, no harm, you
get what you pay for.

But when you use paid contractors and service providers, and what comes out is amateur in both UI design
and functionality, that is unacceptable and arguably FWA.

Seriously, the UI design alone is enough to be so embarrassing as to never release it, but the
click-though logic, such that it is, clearly shows that little to no user testing was ever done, and the
system is being created by either someone who is not a member, or has no idea how CAP actually works.
That or by someone who is taking a canned system and trying to squeeze CAP processes into the OOBE
instead of something that suits CAP's workflow.

In the grande scheme, eServices is both simple and "small", there are probably 10 off the shelf systems that could do it
with only a few weeks of setup, so if the insistence is "home-grown" with a helping of "not invented here"
as icing, it needs to be working on day one, and that goes double for a situation like this, where a fair number
of the bugs were, according to posters here, previously reported and yet apparently ignored.

This is no different then 39-1, where you had early arguing whining moaning collaboration and then in
the eleventh hour it sat on someone's desk, unaddressed, and then was published at the last minute with
plenty of issues, typos, and incorrect or improperly styled graphics.

CAP's ROI is based on leveraging the skills and abilities of the volunteers, and using what they bring to the table.
If everything is double-secret, and last-minute, then the ROI is broken from the get-go and ongoing.

[Fubar]

1)  There are 3 or 4 systems right now out there, not one for each wing

I would love to see a list. I'm aware of CAPSTAR and IMU, what are the others? Can other wings use them?

A couple of years ago I worked up a spec for an API, and all it really needs is 7 functions:

• Authenticate User
• Read Sortie Data
• Read Report Data*
• Create Sortie
• Delete Sortie*
• Modify Sortie Data
• Release Sortie**

* Optional but nice to have
** They may want to retain "Flight Release" as in-interface only, in which case this would not be needed.

Heck, just start read-only and prove the concept works.

[JeffDG]

1)  There are 3 or 4 systems right now out there, not one for each wing

I would love to see a list. I'm aware of CAPSTAR and IMU, what are the others? Can other wings use them?

Those two I'm familiar with...I guessed that there might be one or two I've not been exposed to, and erred on not excluding them.

A couple of years ago I worked up a spec for an API, and all it really needs is 7 functions:

• Authenticate User
• Read Sortie Data
• Read Report Data*
• Create Sortie
• Delete Sortie*
• Modify Sortie Data
• Release Sortie**

* Optional but nice to have
** They may want to retain "Flight Release" as in-interface only, in which case this would not be needed.

Heck, just start read-only and prove the concept works.

I'm missing two...there needs to be a "List Missions" (although without it you'd simply have to enter a "Mission Number" field rather than select one...not a huge issue) and a "List Sorties" function to work reasonably, but just drop the "Delete Sortie" (you can "Modify" it to "Cancelled"), and the"Release Sortie", and you're still at 7 functions for a fully-functional API.

Authentication could be done by one of the well-documented things like OAuth with tokens that expire periodically (so the application can't simply cache the user's credentials).

[Check Pilot/Tow Pilot]

Is the "Status Board" option working for anyone? I just released a flight, but the status board is not showing the sortie. I can see the members signed into the mission on the right side, but the sortie list is blank, even though the mission has multiple sorties and I just released one of them.

Sorties will not show up on the status board until a comm log entry has been added showing the flights actual ATD. It is also necessary to add an ATA before it will be removed from the status board.

Sorties will not show up as planned!

Spoke to NHQ, the status board is broken but will be fixed in the future.

However, if anyone knows the secret of getting the flights to showup on the status board as planned, I'm all ears   Note, the answer is not release them.

[Tim Medeiros]

If everyone here can do a better job than the devs at NHQ, why did you all not apply for the opening over the summer?  They even posted it a second time when the first round yielded no candidates who met the requirements (BS Degree in CS or related field, experience with C# or VB.NET, ASP.NET, SQL, JavaScript, CSS, AJAX).

[Phil Hirons, Jr.]

If everyone here can do a better job than the devs at NHQ, why did you all not apply for the opening over the summer?  They even posted it a second time when the first round yielded no candidates who met the requirements (BS Degree in CS or related field, experience with C# or VB.NET, ASP.NET, SQL, JavaScript, CSS, AJAX).

Perhaps because some of us with that skill set could or would not

• Take a pay cut to work for CAP
• Move to AL
• Any other reason why one would keep their CAP service as a volunteer

As has  been mentioned many times here, there are CAP members skilled in IT Development that are already volunteering for CAP. Some would be willing to volunteer their professional services to CAP. With the proper development / QA / Production setup, some NDA on the PII these volunteers would run across and maybe some other small adjustments you could force multiply the IT development capability of NHQ by an order of magnitude or 2

The recent integration of the paid and volunteer NHQ staff apparently stopped dead at the door to IT

[Eclipse]

If everyone here can do a better job than the devs at NHQ, why did you all not apply for the opening over the summer?  They even posted it a second time when the first round yielded no candidates who met the requirements (BS Degree in CS or related field, experience with C# or VB.NET, ASP.NET, SQL, JavaScript, CSS, AJAX).

I don't honestly recall seeing a job posting - not saying it wasn't there, might have been one of those phantoms
that hits the RSS and disappears before you can click through.

As Phil implies, why is this a paid gig?

This should be on the volunteer side.  Isn't there a National ITO?  Why aren't web devs just part of that staff?
The current CMS may be complex, but that's by design and not necessary.  What we see publicly could be
replicated pretty closely with Google sites or Wordpress, and if it's standardized, then anyone with 1/2 a clue
could maintain it.

[JeffDG]

If everyone here can do a better job than the devs at NHQ, why did you all not apply for the opening over the summer?  They even posted it a second time when the first round yielded no candidates who met the requirements (BS Degree in CS or related field, experience with C# or VB.NET, ASP.NET, SQL, JavaScript, CSS, AJAX).

I don't honestly recall seeing a job posting - not saying it wasn't there, might have been one of those phantoms
that hits the RSS and disappears before you can click through.

As Phil implies, why is this a paid gig?

This should be on the volunteer side.  Isn't there a National ITO?  Why aren't web devs just part of that staff?
The current CMS may be complex, but that's by design and not necessary.  What we see publicly could be
replicated pretty closely with Google sites or Wordpress, and if it's standardized, then anyone with 1/2 a clue
could maintain it.

Instead of spending time trying to develop a mission management system, then releasing something that is about 1/4 done, instead just build a secure authenticated API and publish the specs for it.

Then you'll have some folks who want everything but (or perhaps including) the kitchen sink in a mission management package and you'll get IMU 4.0 (with the developers freed from chasing down every little UI change in WMIRS and posting data via the API, now able to make the thing work better), someone else will come up with a nice simple "SAREX on a Stick" that'll fit on a bootable USB key, another enterprising soul will come up with the Saskatchewan Wing Cadet Oride Management System (used a province instead of a real state to prevent parochialism) that will run Orides incredibly effectively within their wing's constraints.  The point being, they all feed NHQ the information NHQ needs for reporting (which is what the "R" in WMIRS stands for) back to them in a timely and accurate way.

[Eclipse]

APIs and similar standards are what is driving the current App economy, however the one thing
they are >not< is "invented here".

[Phil Hirons, Jr.]

I guess I did imply why a paid gig.

I do think we need some full time paid developers at NHQ. When the SHTF and somethings got to be fixed now! you need someone responsible for that.

In my mind the volunteers would do work on a non-production system with a good portion of "real data" (hence the NDA) as I believe made up test data will never be as messy as the real McCoy.  QA testing could be either paid staff or a combination with production deployment handled by the paid guys.

I do agree with the API idea One size does not fit all missions and there are times I'd much rather be able to work offline and upload as the situation allows. We might actually lose power / internet at an ICP and not be able to get online.

[Eclipse]

I guess I did imply why a paid gig.

I do think we need some full time paid developers at NHQ. When the SHTF and somethings got to be fixed now! you need someone responsible for that.

In my mind the volunteers would do work on a non-production system with a good portion of "real data" (hence the NDA) as I believe made up test data will never be as messy as the real McCoy.  QA testing could be either paid staff or a combination with production deployment handled by the paid guys.

I don't necessarily disagree, but by the same token, CAP expects members to drop everything and run out the door for missions, so that's
not much different then fixing a broken web server, plus between time zones and members with creative work schedules, odds are
a properly scaled team could handle whatever comes up - the days of an IT guy sitting in the same room / building / state as the servers
are already behind us - more and more people, including myself, telecommute as their primary job, some never touching the gear they support,
especially if it's in a data center.

There are also two scales to this, the public-facing website and WMIRS / eServices.

You can argue the latter is mission critical and needs professional support, but the former isn't.  It
doesn't generate revenue, isn't a news stream, and the resources there are not life or property critical.
The main website could absolutely be handled by volunteer staff, and in the unlikely event there was an outage
of even a day or two, who cares?

And we've already seen the glowing work the paid staff are doing with WMIRS / eServices. Even with
teams of volunteer testers and prolonged Beta cycles, things are still rolled out last-minute, missing features,
and in some cases simply broken, so the bar isn't exactly set at "Google" in terms of QOS.

[Larry Mangum]

I am putting together a top 5 / 10 list of things that should be a priority to fox or add to WMIRS 2.0. If you would like me to add your concerns to the list, please PM me.  I am asking you to PM me versus posing your request here because I want to compile the list and send it by Wednesday morning, so I don't have time to wade through all of the arguments and silliness, that arises at times here.

My first items, will be:

1. Usable status boards.
2. Printable ICS forms.
3. Mission / Budget expenditures.

[JeffDG]

Too bad they didn't have a WMIRS 2.0 "Working Committee" before they rolled it out.

One thing on my list:
1.  Authenticated API for querying and updating data in WMIRS.

The rest we can take care of ourselves, thank you very much.

[Check Pilot/Tow Pilot]

I am putting together a top 5 / 10 list of things that should be a priority to fox or add to WMIRS 2.0. If you would like me to add your concerns to the list, please PM me.  I am asking you to PM me versus posing your request here because I want to compile the list and send it by Wednesday morning, so I don't have time to wade through all of the arguments and silliness, that arises at times here.

My first items, will be:

1. Usable status boards.
2. Printable ICS forms.
3. Mission / Budget expenditures.

PM'd you and adding here for discussion by others:

Thanks for doing this Larry.  Here are some suggestions from the CAWG WIMRS Support team.

1. Major changes to the Air and Ground Sortie Grids as follows:
a. Change Approval/Status field as follows:
i. Change "Approved" to a non confusing name such as "Accepted"
ii. Add "e108 Submitted"
iii. Add "e108 Wing Approved" or "e108 Approved"

b. Add the following columns to the Air Grid
i.RELEASED
ii.Call Sign,
iii.Mission Symbol,
iv.Estimated Hours,
v.Actual Hours
vi.Gallons
vii.Fuel Cost
viii.Area of Operations - Quick view of where aircraft
ix.WMIRS Sortie Purpose (objective) (Not in WMIRS 2.0)- For SAREX and RWM - Quick view of Assignment in grid and Status Board is vital

c. Add the following columns to the Ground Grid:
CAPID/License
Make/Model
Call Sign
Miles Driven
Fuel
Gallons

d. Change the Grids to allow for column choosing so each user can customize based upon their needs.

e. Combine the Edit, Brief, and Debrief links into the left most column, possibly use icons to reduce the column height.

2. Add the ability to print ICS 211, 214, 218, 309 Reports in case of a power failure

3. CAP104a:
a. Incorporate F104a information into Debrief, including auto calculation of POD
b. Add ability to enter clues for use by PSC

4. Incorporate F104b information into Debrief with the ability to save the photos, associated shot data, and the metadata. I know we have CAP Uploader and FEMA but there are some missions where public FEMA storage may not be appropriate.

5. Ability to run a single WMIRS 2.0 mission at a base without internet and then merge after the exercise.

6. Disable "Enter New Mission" unless you are an IC or are in an Ops or ES Duty Assignment (or are specifically given this access by someone in a Wing Ops/ES role). Way too many individual pilots mistakenly using this when all they meant to do was Add Sortie for a proficiency flight.