Re: [Tiki-devel] [Tiki-users] doc.tiki.org is down?!
Gary Cunningham-Lee <gary_c-39LOpZwlz1/[email protected]>
| Newsgroups | gmane.comp.cms.tiki.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi again, I made a page -- https://tiki.org/Proposal-for-Handling-Old-Pages -- with more details, etc., about this idea of using categorization to hide old content. I'm basically looking to see if there are objections or better alternatives to this idea because, if there aren't, I'll get started on it. -- Gary On 7/24/2021 3:17 AM, Gary Cunningham-Lee wrote: > Hi, > > I've suggested this before: pages that are basically without value > either delete or, if we maintain the policy to not destroy data, then > categorize them as "Retired" and make them Admin-only access. Pages > that have some merit but we don't want search engines or anonymous > public to access, categorize them as "Archived" and make them > Registered-only access. I suggest not spending a lot of time > (actually, I suggest spending almost no amount of time) examining and > analyzing pages to try to sort out valuable content from not-valuable > within a page. I would just put the page in one of those two > categories if the content isn't relevant to currently supported Tiki > versions or the essentially current situation of the community, etc. > If I had a hard time deciding between putting a page in "Retired" or > in "Archived", I would put it in "Retired". Pages that have old > content, not accurate or helpful to readers regarding currently > supported Tiki versions, but have some merit, would go into > "Archived". (This is subjective for sure -- maybe some > patterns/guidelines would become apparently after doing some pages.) > Then there would be an alert box in the pagetop module zone, module > visibility set to the category so would appear on every Retired or > Archived page, that the content is old and maybe of questionable > relevance and is being kept for historical purposes. Something like > that. I imagine we could improve the situation gradually by everyone > who's interesting spending a little time each week or whatever going > through the pages, maybe with a focus on pages that seem to get > relatively more hits but shouldn't be shown. > > This can be done with the tools we have now, but assumes that the > old/bad pages aren't a drain on resources, just idling in the > database. If they are, to the extent that it's a problem we need to > fix, then the categorization wouldn't be the solution. > > New pages that monitoring needs to look out for aren't created very > often, so there isn't a lot to do regarding those; and they're visible > in the recent-pages module -- it's mostly the old pages that need to > be dealt with IMO. > > -- Gary > > On 7/23/2021 9:17 PM, Bsfez Tiki via TikiWiki-devel wrote: >> Hi Marc, >> >> I agree with your arguments but not with the conclusion. >> >> If we are struggling to find resources to publish/manage 15+ years of >> data and if checking those data is an unrealistic project that will >> take a huge amount of hours. >> Why would we try to do it ? >> >> Monitoring those data will only add extra resources consumption and >> even if monitored, who will analyse and do some kind of action based >> on those reports ? >> It won’t solve the huge amount of time issue to analyse reports, to >> clean pages, to move pages to warn about outdated information, etc. >> I don’t see the point where once we decide a policy actions are >> turned into automatic process done by AI. 😉 >> (while I’ll be very glad to have improvement in the monitoring area >> on Tiki monitoring) >> >> Unless there is a critical reason (and we should agree on it) to keep >> this heavy inheritance my conclusion is that we should move the data >> in a read only area where they’ll use as less as possible resources >> AND where it will be understandable that this is outdated or >> none-used data. (publishing those data are sometimes damaging Tiki >> image). >> >> >> May be a fresh start (reset) is a but too much, but we can decide >> simple criteria for archiving pages (last visited/edited time). >> Other project did that before us and they didn’t die... >> >> >> Bernard >> >>> On 22 Jul 2021, at 16:51 , Marc Laporte <[email protected]> wrote: >>> >>>> For all the reasons above, I think we shouldn't keep 15+ years of >>>> data online >>>> all the time in a Tiki. We should keep them archived somewhere and >>>> available as read only. >>> I don't see how this is realistic with the current community and >>> technology. >>> >>> 1- It would take a huge amount of hours to manage such a project. >>> Determine guidelines, go through content, etc. >>> >>> 2- If we archive them somewhere, we are just transferring the >>> problem somewhere else. What system? who will manage? what will >>> lifecycle? how will links work? etc. >>> >>> We could invest hundreds of hours to clean up data that has no >>> impact on performance. >>> >>> >>> I repeat my conclusion: >>> "The main issue is that we do not have a proper monitoring system. >>> We are somewhat blind to what are the root causes of issues." >>> >>> Once we know the root causes, we can determine a sensible plan. >>> >>> Marc >>> >>> >>> >>> >>> _______________________________________________ >>> TikiWiki-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel >> >> >> _______________________________________________ >> TikiWiki-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > > > _______________________________________________ > TikiWiki-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel _______________________________________________ TikiWiki-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel