The idea is that Tiki objects (wiki pages, blogs, etc.) will optionally have maintainers, an update frequency and a freshness, i.e., how long ago it has been updated. Then, when an object becomes too old relative to its update frequency, Tiki will send emails to the owner reminding about the need to update it.
It'll be an extension to the Monitoring lib (lib/user/monitorlib.php), that notifies users upon certain changes in objects.
Let's take the example of a wiki page. When creating or editing a wiki page, on the Properties tab the user will be able to indicate an owner (user selector, possibly later groups) and the update frequency in days. The operating user will be the default owner.
A new console command, e.g.
objects:notify-maintainers, will sweep the objects and send emails to the owners telling them about the need to update.
A new Relation, e.g.
tiki.object.maintainer will be used to link users to objects. A new Attribute, e.g.
tiki.object.update_frequency, will store the object's update frequency in days. See: Object Attributes and Relations.
New Preferences, e.g.
object_maintainers_default_frequency etc, will be created for this feature (to go in
- Should we have multiple owners and multiple update frequencies? (each owner with an update frequency, if so, how?)
- Multiple maintainers fine, just one frequency per object for now?
- Let's start with Wiki Pages in trunk for Tiki 21.x but to backport to 20.x when stable
- I think there needs to be a global setting for update frequency and then the attribute can override this global setting
- I think there needs to be an option to send an email to a group of admins (a default to be specified globally and as another attribute (tiki.user.object_ownergroup) i.e. a group responsible) - maybe need to support multiple groups - by creating multiple relations? Should the pref for the default be added to the setting in the relations, or added to it? I can see both use cases
- Changed from referring to users so we can add group "maintainers" later
- Would it support multiple owners users (by creating multiple relations)? Or must we create a group and use tiki.user.object_ownergroup?
- Multiple relations are fine, just needs more interface work
- I think it's related but a separate feature from Goals and Recognition but perhaps the Goals and Recognition could be enhanced to use the owner/ownergroup relation or "keeping your object updated" could be setup as a goal in the future.
- I like that it can specify specific owners as this is often different from the people actually last_modified the item.
- I like that it ties into monitorlib so goes through Notifications
- How would the owner (or one of the owners) mark it as "updated" and how would we record who marked it as such? Note that merely editing it may not mean it's in an "updated/fresh" state. Besides other people (depending on perms) may be able to edit it too...
- V2 can have a checkbox showing for maintainers to say they approve it, but that is a bit like staging and approval, needs more thought
- Maybe "owner" could be too strong a title sometimes? Curator, Manger, Keeper? In some situations, it could be better to encourage participation on wiki pages. If there was an "owner" it might intimidate?
- Would be great to see what pages lacked an owner, perhaps with a little "adapt me" button or something like that
- Plugin list? ;)
- What pages someone "owned" could be good information to show on the profile tab.
- Plugin list? ;)
- Perhaps if a page is not marked as updated after a certain point, ownership could be rescinded
- V3 maybe? Let's leave it to humans for now
- Some pages won't ever need a curator. They should be able to be marked as such.
- Managing everything via emails could be tedious, particularly when there is a lot of content (eg. doc.t.o) Perhaps there should be a panel page that lists objects that can show a few of the important things happening:
- Pages least to most fresh, no curator needed hidden (we want to see what needs checking on the most)
- Pages without a curator, most to least fresh, no curator needed hidden (many of our pages will never have curators, but we want a view to assign one.)
- Pages with a curator, least to most fresh, no curator needed hidden (let us keep an eye on if new curators need to be assigned, or unassigned from pages)
- Pages that are marked as "no curator needed" (lets review if there are pages that should be brought back from the dungeon)
- Guardians, newest to oldest (let us see what new fledgling leadership is in the community)
- Guardians, most pages to last pages (let us see who is making the largest contributions to the project)
- A similar page could be available on each user page, showing only "My Adopted Pages (least to most fresh)" So the user can manage their pages well. Perhaps if this information is made public, the freshness status should not be shown, so it can always be "a badge of honour".
- If a page has not been adopted, then within the panel, it might show a link "Adopt me" shown prominently. Otherwise maybe hidden under the little gear with the other options (mark as beyond guardianship, adopt page, assign guardians, remove guardians, update as fresh, unmark as fresh, invite a user to adapt)