What ISLE options should do

[rosiel]

Currently in ISLE we have several options. We shorthand them to make local and make demo but other config must match or causes very different paths:

1. make demo, which uses the "demo" box from docker hub now deprecated
2. make local with ENVIRONMENT=local and no existing site, which builds a very bare bones islandora (no Defaults!)
   2a. make local with ENVIRONMENT=local and an existing site, which builds your existing site
3. make with ENVIRONMENT=custom which builds your existing site
4. make local-install-profile which builds an install profile on top of a base from docker hub
5. make demo-install-profile which uses the "demo" box from Docker Hub.

The install profile ones are now available on the default branch: Islandora-Devops/isle-dc#160. (merged! yay!)

I'm not sure how to come up with an agreement on this, but I made a chart of what I think use cases exist and what I think those use cases would want. This opens up some gripes I have (for instance, the difficulty of testing any changes to Features) but hopefully this can be useful as the start of a discussion of "what out of the box should look like". I'll try to edit it to reflect what others say, sorry for brain dumping, I just hope this can be useful.

Who I am	Evaluator	Maintaining an existing project	Testing code and PRs	Documenting	Starting Out Of The Box on Your Own	Starting Out on your own (Expert)
A content type ready to use	yes	-	yes	yes	yes? And instructions to replicate or customize	NO
Configured to run derivatives	yes	-	yes	yes	yes? And instructions to re-configure with new content types or options	no
Sample content	yes	NO	yes	yes	no?	NO
Nice homepage	yes	-	-	-	yes? feel welcoming	no
Sample views, navigation, etc	yes	-	yes	yes? (be aware what is "core" or not)	yes? basic "content navigation" e.g. menus, collections, etc.	no
Known good state	maybe?	-	-	maybe?	yes? Want it to "work"	maybe?
Latest codebase	yes?	-	YES	YES	-	yes?
BYO Codebase and DB	NO	YES	-	no	no (that's column C)	no (that's column C)
Able to install custom forks of features	no	-	YES	YES	yes - probably required	yes
Able to install new modules (writeable codebase)	no?	yes	yes	yes? - for modules outside that are useful enough to document	yes	yes

[DonRichards]

@rosiel I think this is on the right track. I'm wondering how to translate this into either something actionable or arrange the table to make it clear which of the 5+ build commands does each fall into. Maybe a extra column to specify all the build states that apply.

[rosiel]

I'm stuck once again between documenting "what is" versus hypothesizing "what should be". I'd like to get a bit more work and input on these before diving too far into mapping them to what build parameters they should use. But yes, you're right, that's the end goal.

Essentially, i don't want us to jump to coding these use cases as "oh, that's the local option" and "that's the demo option" because there's too much baggage, and i want to maintain some conceptual separation.

[rosiel]

One thing that came up is the idea of "the latest code". I envision an "ideal" case of one option that spits an islandora with the latest code, with another that uses some frozen in time (but not too long ago!) known good state. The first is done by Ansible. The second use case is what we currently have - except that they never get updated:

• the install profile includes configs that overwrite anything in code
• the sandbox (composer project that includes the install profile) includes a lock file and there is no process to update it.

My suggestion is to come up with a process/policy/procedure for updating the sandbox, and to continue the work started by @Natkeeran and @kstapelfeldt of extracting the configs out of the install profile and into portable modules.

[rosiel]

Let's take a breakdown, then. The "Evaluator experience" is addressed by the web/online sandbox, future.islandora.ca (in the future, will be just sandbox.islandora.ca). It has everything including content. However,

• it is way out of date
• it includes non-representative content (cats and dogs and a book, but we'd rather more repo-like repo items)

Is there a desire for a "evaluator's demo" to be an out of the box deliverable? Is that use case (the Evaluator) fully satisfied by the online sandbox?

(I'm not sure if there is. It would be useful for the purpose of maintaining that sandbox and testing PRs to have a way to generate it locally, but I'm not sure if we're now in the realm of users who have more technical skills, or if we think evaluators want to have a local sandbox to play in.)

Personally, i don't think that anyone building a site should do it off of the sandbox-including-content.  

So, I think for the case of the "online sandbox", if:

• we can have it regularly update its codebase to pull the latest commits,
• and we can change the content out to show off all our content models,
  then we will satisfy the evaluator experience.

[rosiel]

As of now, future.islandora.ca points to sandbox.islandora.ca and is the install profile demo, loaded with good content (and a working front page)! Kudos and thanks to @Natkeeran!