k_UGC,,, k_disk_hog

UGC was discussed in the Rolia bpost and other bposts, but here I’m boldly (no shame) expanding its scope to includes personal exchanges and personal notes.

Perhaps, system/solutions of UGC vs personal_UGC have overlaps?

j4 this bpost .. I spend 10h+/week on blogg + email. More than half the hours are using my personal archive.

incremental_update .. A G5 essential goal , although it sounds irrelevant to an archive system…  incremental_update across months, even years [see those w1r6 bposts]. This goal is highly relevant when I jot down “content” for planning, problem solving, analysis, self-help etc. Dozens of pieces to update in any week, disqualifying many “simple” systems like paper, smartphone, email drafts.

archive_search .. A G5 essential goal of personal or team’s archive (even a “national archive”). For me, gmail+MSOL, Jira, wiki are more relevant than blogs. Paper folders are suitable if they come in the letterbox. Common challenges include [archive_proliferation, outdated_content, x_ref,,,]

Terminology .. x_ref is a technical /challenge/, but not a “problem”.

==== 温故知新 .. including DRamRefresh is a G2 goal for my “system” . Finding long-forgotten pearls of insight. Common challenges include [x_ref, outdated_content,,]
I now rely more on blog tagging (a system adjustment ) for x_ref.
* A big tcost and real complexity is categorization. I have invested a lot in my category hierarchy.
* A challenge is … tag_proliferation. I have invested into header keywords as an innovative adjustment.

As a system adjustment to help the SEng[search engine], I allocate time to bpost title drafting and continuous adjustment. Search result only shows blog title!

A common challenge is … archive_proliferation i.e. “too many Drams to refresh”. My t_fuxi tag + sticky flag, and fuxi files in git blog are not very effective but still a worthwhile ongoing adjustment. Post-it and print-for-refresh are time-honored techniques.

nuts ##forgettable truths .. is an example of a tradeoff. After a few years, the valuable content (a “Dram”) deserves a welcome refresh but until then, we have to keep it as “outdated, low-value baggage”.

As I age, this goal and its challenges will grow. May become a #1 goal.

For devTill70 and career longevity, DRamRefresh would be crucial, as I use personal_UGC to record technical/localSys/past project content.

— a common challenge is … outdated_content. Most emails and bposts beyond 10Y prove irrelevant.
I now allocate some effort (adjustment) tagging them as outdated.

To reduce noisy search and to reduce storage footprint, I actively remove (adjustment) outdated content from blog and email archives.

In Rolia, only hand-picked conversations are preserved in 精华区 (system adjustment) for years, but a good post was often followed by low-quality comments 🙁

xp: dozens of bposts on diet/nutrition/BMI; dosens of bpost on parenting…

For these goals, A simple “write-n-archive” system without adjustments would soon prove primitive.

— xp: my recoll. Many purposes, including incremental_update and 温故知新. Stopped using it in my early 40s, because … (among other reasons) hard to access from outside home. “Title” space too limited 🙁 No version control

For localSys notes, I still rely on recoll.
— xp: I used blogger and free wpress for years. Limited tagging. Date editing too cumbersome.
— xp: wpress post comment and “updates” on page top .. are simple adjustment for incremental_update
— xp: wpch[wpress commercial hosting]  is my current system
GitBlogg “noblog” files .. as an adjustment and a archive, dramatically reduces my pain of creating/updating too many bposts, but at a small cost ! The noblog Dram doesn’t get enough refresh, but I can live with that.
— xp: English vocab and Driving blogs
DramRefresh is non-essential. Blogger, recoll,,, would probably sufice, though wpch offers additional benefits
— xp: personal email archive, esp. in my Gmail. I seldom use Gmail for active DramRefresh, because largely immutable, and archive_proliferation. I sometimes notice valuable /conversations/ in this 20Y worth of email “haystack”, thanks to the advanced SEng [search_engine]

To reduce noisy search and to reduce storage footprint, I invested in multiple adjustments to clean out worthless letters. Described in a separate bpost.

wechat/whatsapp messge personal archive is used by many individual users… poor cousin to email archive. Limited screen; no subject; limited history.For important data, better send email to myself.
— eg: A Goldman colleague shared his “team best practice” .. saving all email discussions in some /undisclosed/ knowledge archive, which proved effective for finding long-forgotten pearls of insight.  I see multiple imperfections

• lots of the content are duplicated/repeated,
• Some of the content is low quality, even incorrect/misleading
• alternative spellings and (rare) misspelling would mess up the poor SEng

ExpertExchange and Quora suffered the same. Stackoverflow has many adjustments to reduce those pains. Those features are costly and complex.

A corporate wiki is better maintained but still lacks an effective SEng.

— innovative adjustment : /disposable/ blogging
* tcost: updating existing bpost .. obligation to find the _most_relevant_ bpost. After that, often need to integrate new content into existing.
* tcost: creating brand new bpost… obligation to choose category/tags and draft good title
* tcost: noisy wpress search /against/ increased haystack;
* tcost: overcrowded category/tags

When I have too much content in git-blog, a recommendation is … disposable blogg i.e. expressive, reflective, therapeutic writing in git-blog (or wpress), and later move content into those fuxi_*.txt files

Email with friends .. is an exemplification of such reflective writing and comparable to disposable blogg. “Thrown away” into gmail archive. better tcosts. Eg: in early 2024, I did such an reflective writing on “adaptable retirement”. These emails are kinda worth a dramRefersh once a while, but … Should they go into my blog as four-liners? Only a selected few.

Need to go through the fuxi_* files once a while or they would keep growing, but that’s a tradeoff.

Sugg: split fuxi_ files by subject