Post History

I think the framing of this question (and the prior discussion) is wrong, and I think that conditions have evolved since it was originally asked - in particular, we can now see how articles have turned out for other communities. Rather than try to define "wiki" or consider ways to implement that strategy, I want to consider:

**How could a category using the "article" page type be used here?**

My own answer seems quite clear to me. The model that makes the most sense is already demonstrated by the ["Papers" section for the EE community](https://electrical.codidact.com/categories/35). The examples here generally look, to me, like one of:

* Guided "tutorials" that build to an existing concept step by step (e.g. the actually-existing design of basic op-amps)

* Closed-ended, but non-trivial, lists of well-agreed-upon reasons for a practice, or methods for some objective. These are susceptible to being presented in a way that looks more like Q&A, because there is more of a need to specify the underlying problem in detail.

* Alternatives for ways to visualize or understand a difficult or subtle concept

All of these make sense to me in a software development context, although I would modify the last one somewhat - we might instead have articles that focus on a single, commonly misunderstood concept (say, recursion), and address multiple misconceptions with that same concept. I'm a little less positive about the idea of doing tutorials, but I can imagine offering e.g. a collection of ways to do individual tasks that sum up to "managing a language-X environment" or "making use of branches in a repository" or "choosing between absolute and relative imports in Python". You get the idea.

Where I think this model could really shine is for the medium-length-list type questions, where there are a few well-defined ways to do something simple, and a fair bit that is useful to say about each of them. For example, the nearly 3000 words (if we count the dozens of short code examples as text normally) I recently wrote [about string formatting in Python](https://software.codidact.com/posts/289251). When there are fundamentally about 6 (depending on how you count) sensible approaches to a problem, that isn't too widely scoped for a question (the question itself is quite coherent, and would look the same if there *weren't* the historical baggage of `%`-style formatting etc.). It offers an executive summary that [fits within short-term memory](https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two). But being able to put all the answer content in one place, up front, avoids a [combinatorial explosion](https://meta.stackoverflow.com/questions/390907) of attempts to explain various *subsets of* the Ways To Do It (and of various aspects thereof). It also avoids confusion over whether to answer with a summary of all ways, or in detail about one way - more importantly, it avoids worrying about *coordination* problems between answerers.

The potential downside I see is that (as things stand, to my understanding) articles could not be *directly* used to close duplicate questions, at least not if they're in their own category (which would IMO definitely be desirable for organizational reasons). But then, a lot of the time it would be better to answer questions with a "stub" that *refers to* main article content (and perhaps points out a specific relevant section) and then in some cases it could be closed after that (as no other answer could reasonably be necessary). Possibly in some cases, *those* questions could become really good duplicate targets. The stub would give a direct answer for a very specific question, and then relevant detail is behind the link (just as it would be for answers that quote and cite documentation and then give a one-sentence explanation of how the quote answers the question).