Re: [Tiki-devel] [Tiki-users] doc.tiki.org is down?!

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