joinedupack / Roadmap

0 stars 0 forks source link

Site Archival Policy #16

Closed bbertucc closed 2 years ago

bbertucc commented 3 years ago

Short description

Eliminate out-of-date content and sunset stale sites.

User Story: Tulane University

“As a Network Admin, my university's acceptable use policies need to be inline with how a user's content is published and sunsetted. University administration is scared that unauthorized users will publish unapproved content under my institution's branding.”

User Story: Lafayette College

Lafayette College has a policy related to archiving and deleting sites: https://its.lafayette.edu/policies/archiving-renaming-and-redirecting-websites/

Currently, the policy must be manually implemented because there are no tools to automate the process. Manual updates are prone to user error and use human resources that can be automated.

User Story: Harvard University

Kate at Harvard has two requests around sunsetting:

  1. Sites by Harvard students need to be archived 9 months after sites are created. This is a policy at Harvard. They have no way to manually crawl sites to test for student eligibility.
  2. If content has not been updated in a year (or two) there needs to be an option for the site to be renewed or archived. This is not a set policy, but a nice to have.

How should it work?

This "User Story Editor" feature allows Network Admins to set system actions that are triggered by user interactions or time-based milestones.

On a single WordPress install, admins accesses “User Story Editor” from the Edupack “Core Features” list or from under the “Appearance” tab. Multisite Super Admins can access “Core Features” under the Network Settings tab or from the Edupack “Core Features” list.

The “User Story Editor” view includes a list of existing User Roles and summary of user stories within the role (ie- “2 Stories, 8 Waiting Periods, 17 Events, 20 Actions” or “No Stories”).

When adding a new user story, you must first select a user role (ie- “Teacher”). Then you add the first user event (ie- “Account Creation” or “Content Publication” or “Content Deletion”). You can then add a “Waiting Period” (ie- 20 Days) followed by a system action (ie- “Email Notification”, “Delete User”, “Publish Post”, “Archive Site,” “Delete Site”).

Any existing user story can also be edited, removing any item or adding new items after/before any user event, system action, or waiting period.

Editing this page in any way saves the user story.

Is this ticket blocked by any other dependencies?

Needs more specific user stories.

What are the views that need designing?

Next steps

nathansmonk commented 3 years ago

I really like the idea of writing user stories to create governance flows. I think starting with "A simple..." Is a bit cruel though 😂

I'm really interested in knowing:

bbertucc commented 3 years ago

@nathansmonk - removed "A simple" .. this is def not simple 😬 ..

"Actions" is a term just for simplicity to explain the UX. I imagine these would be built from different WP hooks, like draft_to_publish.

Re: Gravity Flow.. A question for you: Would it be more of a pain to develop all the steps that Lafayette college has as a custom extension for Gravity Flow or develop this Edupack feature? If it's about the same headache, why wouldn't we build our own feature that we could tune better to Higher Ed needs than relying on the Gravity Flow team?

nathansmonk commented 3 years ago

"Actions" is a term just for simplicity to explain the UX. I imagine these would be built from different WP hooks, like draft_to_publish.

I'm assuming that the user stories would guide what actions are made available in this feature set then?

Re: Gravity Flow.. A question for you: Would it be more of a pain to develop all the steps that Lafayette college has as a custom extension for Gravity Flow or develop this Edupack feature?

The Lafayette example is quite different to the one in "How should it work?" In fairness, you probably couldn't do what lafayette needs in gravityflow, but it could comfortably do the examples in "How should it work?". I could probably knock the latter up in a few hours or less in GravityFlow - it wouldn't even need a custom extension. It would just be capable out of the box. GravityFlow is great for site content (if a little bloated), but not for network/site administration flows. If we're to look at both of these types of things (site content and site management) then we should probably split it into two tickets, so we can assess each independently. I would say theres more of a gap in the market for site management right now.

bbertucc commented 3 years ago

@azito122 - Did you test out Gravity Flow to satisfy some of your automation needs? As @nathansmonk points out, that might satisfy some steps in Lafayette's procedures. .. I imagine no automation tool could satisfy those manual review pieces..

nathansmonk commented 3 years ago

I think there might be some disparity at the moment between the user stories and the requirements.

We should probably be super clear on what strand of governance is this. To me the user stories represent site sunsetting. The requirements elude to content governance too. I believe that they are two distinct workstreams. This ticket should be site sunsetting. If that were to be accepted, I think the user story editor might actually be overkill. There appear to be common themes in the user stories (if not updated within a certain timeframe) which could probably be handled with a simpler set of options.

bbertucc commented 3 years ago

Do you mind updating the ticket to do what you’re requesting? Feel free to hack and edit the ticket(s) as you please.

On Wed, Apr 21, 2021 at 6:31 AM Nathan Monk @.***> wrote:

I think there might be some disparity at the moment between the user stories and the requirements.

We should probably be super clear on what strand of governance is this. To me the user stories represent site sunsetting. The requirements elude to content governance too. I believe that they are two distinct workstreams. This ticket should be site sunsetting. If that were to be accepted, I think the user story editor might actually be overkill. There appear to be common themes in the user stories (if not updated within a certain timeframe) which could probably be handled with a simpler set of options.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/joinedupack/Roadmap/issues/16#issuecomment-823989473, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALMPGHTWU2GN7FWF2ONYLTJ2ZR5ANCNFSM42ZS3JUQ .

bbertucc commented 3 years ago

Note: Will need to update Tulane's user story.. it includes user capabilities, which "sunsetting" does not deal with

bbertucc commented 3 years ago

Bill inspired the question.. What happens when the student wants to "take their website with them" when they graduate? At Dartmouth most are fine with having it deleted, but some want to keep it. They don't have a process for that, so it requires manual work. Maybe this can be added to our workflow?

dartmouth-mlacak commented 3 years ago

Other options for "take their website with them" is to provide a backup (DB & files), or to offer a migration path, like Reclaim Hosting has with "Domain of One's Own".

dartmouth-mlacak commented 3 years ago

With regard to "last update" triggers, this works well for many sites, but we have found conferences and research projects are often exceptions. With these sites, the information doesn't get updated, but needs to "stay" because published materials link back to the site. So there needs to be a way to flag a site as an exception to the rule.

nathansmonk commented 3 years ago

Re: "What happens when the student wants to take their website with them when they graduate?"

I think this is more complex than I originally gave it credit for. WP's default WXR files are a good way to port your content, but that gets pretty complicated when your content becomes dependant on a plugin. For example, if you run events through the events calendar pro, or worse - if you add a page builder like WPBakery. At that point, your content is worthless. I'd love to be able to say 'well don't do that' - but I think thats pretty unreasonable. And that's just one complication.

You only have to look at wordpress.com to see that even their migration guide puts WXRs as option 2. Jetpack has its own migration tools to get you to .com.

I know we have a dedicated tickets for migrating sites in to edupack, but I think we could probably do with one for migrating sites out too. I this this is a feature that is functionally different to site archival, but can absolutely see the close relation.

andyzito commented 3 years ago

I've only played with GravityFlow a little bit, so I'm not familiar with what exact automation steps it could support. Manual review pieces could be implemented by a pause in automation w/ a manual "continue" button (or something like that), if that's a thing GravityFlow could do.

I agree that WXRs are problematic. The biggest issue we run into is that the site has to stay up until an import is complete in order for the import to pull down the images. When we want to migrate sites behind the scenes we use the excellent mu-migration, but that's not viable for this use case because both exporting and importing are done through the CLI.

nathansmonk commented 3 years ago

Thanks @azito122, that's really useful insight.

I've seen people use photoshop to crop an image. That kinda feels like a good analogy for gravity flow and your issue here.