Sorry if this has already been answered. I haven't really figured out stackexchange yet. But what time period is retro computing? From the beginning to the 80s? 90s? Early 2000s?
This is a question that comes up every now and then - in fact, one of the very early ones on Meta.RC.SE already asked "What Constitutes Retro". And while the most favoured answer back then focuses on the fact of real, every day usage of otherwise outdated systems, todays concensus incooperates a wider range of outdated systems, but especially theoretical and research questions about old software, hardware and culture in general.
While age does not scale as well as a first thought may imply, there is a general notion that systems less than 20 years old do need a good reasoning to be on-topic. Also, questions involving main stream architecure like a 1999 PC will have a harder time than obscure offside developments like a Motorola Marco.
The defining point is also less the exact date of a certain hard or software, but rather the intention and focus of a question. Emulators are eventually the best example here: Questions that would have been the same, with the original hardware (*1) are without any doubt on topic. Further some about the emulation could be on-topic (*2,3). But questions about handling of an emulator and interaction with modern hardware (*4) are complete off-topic.
Bottom line: RC focuses more on content than any arbitary time stamp.
(For a wider perspective, try a search for "topic" on Meta.RC.SE)
*1 - "How to save a source in BigMac to be read later on by AppleWriter"
*2 - Like asking how a certain instruction should be emulated.
*3 - I wouldn't even mind questions about emulation techniques, as they, even while targeted and tied to modern software development, are relatable.
*4 - "How to operate my USB3.0 hyper reaction time joystick with MAME on Windows"
Raffzahn is correct that question content, rather than a particular time, determines how on-topic a question is; after all a lot of questions cover techniques still used in modern computing and are justified here merely by their retrocomputing focus. That said, there are several areas where others disagree with him.
One area would be exactly that: overview questions about techniques still used in modern computers. The classic example here is "what is DMA and how does it work?" Several people think it's off-topic and retrocomputing users should first go elsewhere and learn about DMA in modern systems before discussing it here. Others disagree and feel it's reasonable to learn about DMA only as used in retrocomputing systems, and ignore the modern version.
Another is the idea that many specific questions about developing on specific retrocomputing systems should go into those systems' forums, rather than here: "RC.SE won't become a Stackoverflow for such." This hasn't been discussed much, but I, at least, disagree with that (as do, apparently, the many people who have asked and answered extremely system-specific questions). Not only is there no clear dividing line or even zone for this, but it goes against the whole general idea of StackOverflow/StackExchange, which is to provide a Q&A site that covers, in a different way and form, what has always already been covered in discussion forums since before SO started.
I would suggest that a good criterion for any question would be, "is the answer you produce more than trivially different when discussing it in a retrocomputing context?" That would make "What is a linked list?" off-topic, but "What is X" on-topic if it's something differently-known or -used in modern systems and it would be reasonable for an introduction to retrocomputing to discuss it in a non-trivially different way for modern developers than an introduction to modern computing for modern developers. (We need to keep in mind that a significant fraction of our audience may know a fair amount about programming, but learned it in the 2000s, not the 1980s.)
I would say that if it's gone obsolete and then regained some interest afterward it's retro. That would work for entire platforms, for software, and also for generations of long-lived platforms.
- The older it is the less there is to prove.
- Things that are not yet obsolete are out.
- Things that are obsolete but nobody yet feels any nostalgia for are borderline.
I don't see any point on picking specific years, as they would have to be updated every year anyway. You could pick 20 or 21 or 25 years, but some things probably go retro faster than others and why not leave it to a case-by-case basis?