Changes between Version 1 and Version 2 of Ticket #590


Ignore:
Timestamp:
09/06/13 12:02:34 (3 years ago)
Author:
jim
Comment:

Added proposal E: Review site features... moved old E to E.2...

Ed, do you want to drive this on your return? If you make a list of things you feel we've outgrown or have fallen aside along the way, I can review the likely impact of those... I've added E.1 and E.2 for starters.

Also added time estimates to proposals.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #590 – Description

    v1 v2  
    55I also note that many of these cleanup operations will also help make the move to D7 smoother and better. 
    66 
    7  
    8 '''Proposed fixes''' 
     7= Proposed fixes = 
    98Ed, please confirm you'd like me to do these, or if you need more info. 
    109 
    11 '''A) Remove spam taxonomy entries''' Low risk, low reward -- See item 8 below. A simple delete from taxo term table where length > 50 is worth doing IMHO, and nothing I saw that would be clobbered is not spam. 
     10'''A) Remove spam taxonomy entries''' 1/2 hour, Low risk, low reward -- See item 8 below. A simple delete from taxo term table where length > 50 is worth doing IMHO, and nothing I saw that would be clobbered is not spam. 
    1211 
    13 '''B) Try a Taxonomy Cleanup''':  Medium risk, medium reward -- style module to try to merge terms with the same names and clean up the link tables back to nodes. Further, we can remove any taxonomies or relations to certain CTs that don't really add value. 
     12'''B) Try a Taxonomy Cleanup''':  3 hours, Medium risk, medium reward -- style module to try to merge terms with the same names and clean up the link tables back to nodes. Further, we can remove any taxonomies or relations to certain CTs that don't really add value. 
    1413 
    15 '''C) Find Variable table writes and kill them''' -- Per item 9 below:  I see plenty of SELECT * FROM variable calls, which imply a cache clear due to a variable being set. In normal use variables shouldn't be set (admin screens tend to do this), so I'd like to try to see what module it causing this and patch/remove it. 
     14'''C) Find Variable table writes and kill them''' -- 3-8 hours, medium reward, low risk -- Per item 9 below,  I see plenty of SELECT * FROM variable calls, which imply a cache clear due to a variable being set. In normal use variables shouldn't be set (admin screens tend to do this), so I'd like to try to see what module it causing this and patch/remove it. 
    1615 
    17 '''D) Review Views caching''' low risk, high reward -- this was done a while back but I think 
     16'''D) Review Views caching''' 1-2 hours, low risk, high reward -- this was done a while back but I think 
    1817 
    19 '''E) Kill Microsites and the Forums''' -- Low risk, '''game changer''', high reward: -- then remove OG and Forum modules. In D6 these are known to be performance killers. We could alternatively migrate the forum to a simpler setup (not using forum module) that leverages Disqus or other services to offload comments and moderation.  
     18'''E) Review site features, kill what we don't really need''' Low risk, '''game changer''', care needed, medium reward -- Let's start reviewing the site and make a short-list of things that have had their day. Ed, do you want to drive this on your return. 
     19* '''E.1) Remove 'Geographic region' and related taxonomy and Hierarchical Select modules''' 1 hour, low reward, low risk -- never really been used and is effectively a duplicate of the location field. let's kill it! 
     20* '''E.2) Kill Microsites and the Forums''' -- 3 hours, low risk, '''game changer/needs confirmation''', high reward: -- then remove OG and Forum modules. In D6 these are known to be performance killers. We could alternatively migrate the forum to a simpler setup (not using forum module) that leverages Disqus or other services to offload comments and moderation. Either way, the handful of people using the CMS feature should be migrated to Open Atrium if they need such features.