Improving the Steem platform for long-term content

I've been working steadily over the past couple days on one of the routine housekeeping tasks that's been neglected of late, namely, getting our Github issue tracker under control -- sorting, opening, closing, and replying to various tickets. As the ecosystem's grown and matured, I've discovered a need to change my personal workflow away from the development-oriented workflow I used in early Steem days, back to the more issue-tracker-centric, maintenance-oriented workflow I used in the later BitShares days. Which, among other things, means classifying every single ticket in my personal Zenhub according to how urgently it needs my attention. So I've been looking at a lot of tickets lately.

This ticket started out straightforwardly enough, as a request to revert the change which limits posts to two payout cycles. As I stated in my reply to the ticket, the reason we decided not to do this is to reduce our memory usage and limit the working set which needs to be kept in memory by consensus nodes. I would ordinarily have closed the ticket right then, but it was generating a lot of high-quality discussion, so I decided to let it run for a bit. I'm closing it now, though, and asking the discussion to continue in the comments here.

At first, I was a bit puzzled by the degree of controversy this straightforward change created. After all, Reddit archives old posts and discussions, disabling any updates or upvotes, probably with similar technical justifications, and nobody's up in arms about it.

But I eventually figured out what's going on here.

It's been my working assumption -- and likely the working assumption of others on the development team -- that Steem is all about fresh, new content; the value of content rapidly diminishes as its age increases. Many aspects of the system -- for example, how the sorting works -- are also designed with this assumption in mind. Let's call this Type I content.

But there is another type of content. A wiki, a blog, a Stackoverflow question, or (ironically enough) a Github ticket may continue to be relevant long after it is published. Let's call this Type II content. For another ticket I asked Hive account@dantheman for his opinion on where the canonical location for build instructions should be; his answer was to place them in the source tree. This was a simple, straightforward practical question with a simple, straightforward practical answer, and neither of us thought much about it at the time. But the question we should have asked ourselves was this one: Why don't we store the build instructions in Steem? And the answer is that build instructions are Type II content, and Steem simply isn't designed for it, which meant we'd have too many annoyances if we tried it.

In short, our focus on Type I content means that Type II content is something of a second-class citizen. And the assumption that we don't care about Type II content has become deeply ingrained in our thinking, to the point where we'd stopped noticing the missed opportunities.

So here are the questions I'm going to ponder:

• If we were designing Steem from the ground up, but we decided to design it with a focus on Type II content instead of Type I content, what choices would we have made differently?
• What is the right path to making Type II content a first-class citizen in Steem?

I haven't even begun to properly consider these questions, but I think they're important. What do you think?