I’d prefer to not start another list of questions/answers, I think having too many indexes make the content harder to find. Maybe these could go in the FAQ? Alternatively, they might belong in the howtos(eg. move the content of ComponentsDontFindTheirModels into a note on a Component howto page?
LeeO
I considered both places but found neither to be acceptable:
- FAQ means these are frequent questions. They aren’t. And the FAQ is a little messy and unreadable.
- Howtos means you get a clear description of what to do to acomplish a specific task. These topics aren’t tasks and they don’t give a clear answer.
I think both of these are open questions and describe a problem that traps some people. If their solved, move them to Howto if they read like a howto. But I am open to discussion…
Magirus
I agree with your assesment as to why these dont fit well in either the FAQ or the Howtos. I’m still not sold on this as a solution. I still think that issues that trip people up will more easily be found when they are attached to pages about those topics, instead of a generic “it doesn’t work” list. For example, \MySQLDatabaseAccessProblem would fit quite well linked from the MySQL page, and ComponentsDontFindTheirModels could link from a page about components.
I guess what I’m saying is that I think it makes more sense to organize the content by subject rather than group them together because they’ve all tripped people up. — LeeO
Perhaps a list of Error messages and their possible causes with a more detailed explanation of the processes involved in the error, etc, would be useful?
- I had a somewhat fuzzy thought about using IRC logs to gather errors and solutions. Frequently people will post their error message to IRC, or post it to rafb.net/paste and then post a link in IRC.
-d723
Good thing. A List of explanations to error messages would be very helpful. I second this thought.
Lee, I think the problem is that people often are in a starting situation to some topic and first get around the problem and the around what topic it is in. From a researchers perspective you are absolutely right, but I feel this site (and Rails) is more about experimenting than about researching and then trying to get it work.
I read the Getting Started, run the installs, type in the Tuts and then: Bäng I need help. Mostly without knowing why…
— Magirus
An error message list, or translator would be very useful indeed. Maybe even a (lightweight) troubleshooters guide?
I’m not sure about the research vs. experiment analogy… though I suppose that links are cheap, so why not have it work both ways?
I strongly feel that problems(common, or less so) and (hopefully) workarounds should be kept with the main page for that subject(be it \MySql or Components, or whatever). That doesn’t mean though, that we can’t also have an index of common error messages that link to the specific info.
— LeeO
I’ve added “Troubleshooting” section to the MySQL and Components pages. I think providing access to this information in this way solves the problem by allowing users to access the solution by either starting with the subject(eg. mysql) or the symptom. Either way they find their content.
The (only?) downside is that there is more content to manage, which seems like a reasonable comprimise.
— LeeO
Precisely: the beauty of a wiki is there are many ways to find the same content. Personally, I relish a list of problems and solutions. I can read them and learn something even without experiencing those problems.