This is a series of side-notes to @Glen_b's excellent answer.
The editing process
Editing is a public service. Even some small edits can just clean up a post and make it easier for everyone to read, which is a positive contribution. Often an edit can change a question that looks too messy to wade through to one that looks readable. Editing can and should help the OP, who should get more and quicker attention (and, although this is a side-effect, who should also get feedback on their presentation for future questions). It helps others too.
Editing does not impart a moral judgment. We can't confidently and consistently distinguish between over-hasty, lazy presentation and someone struggling with one, two or even all three of a second language; statistics they really don't understand; and a medium that is unfamiliar. That said, I will on occasion comment firmly that a question (or answer) is just too messy to be worth anyone's time to edit. If the OP isn't able or willing to fix the presentation, then that is the end of the story: we are all volunteers here and there is no obligation to be infinitely helpful.
Editing even one small thing requires a careful decision. It will bump the question momentarily to the top of the active list. Some people are irritated to re-open a post of interest to find one minute change. But even threads that have seen many posts can carry errors worth correcting. Nevertheless, for this and other reasons, it is good advice that if you edit, edit everything that you spot as deserving change, so as to make the edit worthwhile.
Editing titles, tags and commentary
Editing just the title can be valuable. Posters can be especially blind to typos in the title. Considering that titles are key for later searches, even trivial misspellings can be a nuisance. It's common that titles are too long and/or carry useless words (please help; question about; how to analyse my data). On the other hand, sometimes you need to flag to posters that they should think up a better title themselves. (It's a fact of life in a forum that some members use eccentric or inadequately informative titles as a criterion for what to ignore, so improving them may seem a disservice too.)
Editing the question itself can help. Cut out wording such as "My question is" or "The question I would like to ask is". Feel free to add a question mark when needed grammatically or to emphasise a precise and concise question, say by isolating it as a single paragraph or by recasting it in bold. If you can't identify a clear question at all, that is cause for comment rather than an attempt to rewrite the post.
Editing the tags on a post can be valuable. Posters often omit tags that are highly relevant (e.g. data-transformation
) or specify tags that are fairly useless (e.g. mathematical-statistics
for almost any post). A sensitive exception is the self-study
tag, which ideally should be added only by the original poster to show self-awareness of the condition. Otherwise, disagreement over tags is easy enough to fix, so it is fine to edit if you are confident that you can improve tags.
Edits should remove greetings (at the beginning of a post) or signatures (at the end) and any material that looks irrelevant to the question. That includes polite (or even not so polite) expressions of how confused the poster is, how much time they have already spent working on the problem, how grateful they will be for an answer and (especially) how urgent or important the question is. Other comments that can usually be cut include claims that the question is quick, easy or simple: sometimes such claims are just wrong, and when they are right they don't illuminate the question.
Edits should focus attention on the technical content of a question, rather than the human side. In a busy world, being able to read that content quickly and easily is a bonus for all. (I leave open whether it's a benefit that editing sometimes makes it clearer that there is no underlying precise and concise question.)
Editing issues with statistics
Edits can change presentation in any aspect, but as far as possible should only clarify, not change, the statistical content that defines the question being asked. Aspects of presentation to edit can include grammar, spelling, punctuation, and other styling of text, math, code or data.
Edits should not change strange or even incorrect uses of statistical terms, or any other dubious statistical content, even for obvious errors. Naturally, you should only change the language if you are confident that you are right (or have better taste or style...)! (Don't worry too much about this; a mistaken edit can be reversed.)
There is, as often, a small tension between the immediate, short-term aim of helping the original poster and the ultimate, longer-term aim of building an archive of high quality answered questions that should be of interest or use to many readers (in many cases, long after a poster may have disappeared from the forum). But any errors, omissions, or confusion in the statistical content of a question are likely to be part of the OP's problem and should be left as posted. Someone who edits a question may not intend to answer it, but can help by publicising difficult points in comments. For example, you say that you want to apply multivariate regression, but you only have one response variable, so I think you mean multiple regression.
Edits can introduce or improve mark-up of mathematics, code and data, but should not change even poor notation choices, which could be part of the problem. I would correct trivia, as when someone has posted $\beta2$, but it's evident that they mean $\beta_2$, but if in doubt, do not edit, but rather comment. There seems to be a square missing from your variance formula.
Editing graphs and code
Edits should rarely replace someone's graph. But here is a further situation where that does seems right: when presented with a very crude hand-drawn graph that someone has scanned or photographed, you may without loss be able to do a much better job.
Any editing of code should be done with caution, especially if incorrect or inappropriate code may be part of the problem. In such cases answers should explain and suggest ways to improve or correct the code. There are limited exceptions. For example, long lines of code are awkward or annoying to read if they require horizontal scrolling. Editing the code to fit within the visible question window -- using any essentially cosmetic change -- is a small public service. You can also insert blank lines to divide the code into smaller coherent blocks. But you need to be sure that your edits do not change the meaning of the code or affect whether it runs as written. When in doubt, do not touch.
Appendix: common statistics typos
This is a list of some common typos arising in statistical literature.
Seekers of causal links should never be casual in reading proofs.
Users of cluster analysis should note the spelling dendrogram (not dendogram): compare rhododendron, dendrite, and so forth.
When distributions, models, measures or methods are named after people, giving initial capitals to their family names is good practice. Examples are Gauss, Gini, Likert, Markov, Pearson, Spearman.
Software: Proprietary names include MS Excel, MATLAB (although to avoid shouting Matlab is, IMHO, good practice) and emphatically Stata (not STATA).
The following statisticians' and scientists' surnames end with "s", so watch out.
Thus whatever is
attributed to them is tagged with (e.g.) Jeffreys or Jeffreys', but not
Jeffrey's.
Frank Ephraim Grubbs 1913–2000
Larry Vernon Hedges
Harold Jeffreys 1891-1989 (not to be confused with William Hamilton Jefferys III 1940-)
Colin Lingwood Mallows 1930-2023
Brian W. Matthews 1938- (Matthews correlation)
John P. Mills fl.1926 (Mills ratio)
Robert Hough Somers 1929-2004 (Somers' $d$)
Stanley Smith Stevens 1906-1973 (scales of measurement: NOIR)
Herbert Arthur Sturges 1882-1958 (Sturges' rule for histograms)
Samuel Stanley Wilks 1906-1964 (but note Martin Bradbury Wilk 1922-2013)
Peter Ross Winters 1929-2018 (Holt-Winters)
Frank Yates 1902-1994
Here are some other surnames that are often mangled in writing.
Ole Eiler Barndorff-Nielsen 1935-2022
Carlo Emilio Bonferroni 1892–1960
Carl Harald Cramér 1893-1985 (NB accent)
Student 1876-1937 was William Sealy Gosset (not Gossett)
Richard A. Leibler 1914-2003 (not Liebler)
George Pólya 1887-1985 (NB accent)
Alfréd Rényi 1921-1970 (NB accents)
Henry Scheffé 1907-1977 (NB accent)
Gideon Schwarz 1933-2007 (not Schwartz) (BIC)
Hermann Amandus Schwarz 1843-1921 (not Schwartz) (Cauchy-Schwarz)
Leonard Henry Caleb Tippett 1902–1985 (not Tippet)
Bernard Lewis Welch 1911-1989 but Roy Elmer Welsch 1943-
Frank Wilcoxon 1892–1965 (not Wilcox or Wilcoxin)
Charles Paine Winsor 1895-1951 (not Windsor; hence Winsorize not Windsorize)
Some people cited in statistics share surnames. Were they relatives?
Bernoulli family. There were lots of them.
Playfair family. John Playfair (1748-1819) was brother of William
Playfair (1759-1823).
Pearson family. Karl Pearson (1857-1936) was father of Egon Sharpe Pearson (1896-1980).
Coxes. Gertrude Mary Cox (1900-1978) was unrelated to David Roxbee Cox
(1924-2022).
Kendalls. Maurice George Kendall (1907-1983) was unrelated to David George Kendall (1918-2007).
Some bad Greek and Latin is common.
"polychotomous" is bad Greek, probably arising from a misunderstanding
of "dichotomous", which is "dicho" + "tomous", not "di" + "chotomous".
"polytomous" is better.
One criterion, two or more criteria. So never "a criteria".
"data" in Latin means "given things" and is a plural. What this implies
for modern languages is discussable. See also comments below.
"strata" in Latin is another plural. "stratum" is the singular.
Some people want to insist that "heteroskedastic" and "homoskedastic"
are the correct spellings. (There was no "c" in ancient Greek.) This
argument was published in Econometrica. Oddly enough, the spellings
"heteroscedastic" and "homoscedastic" are due to Karl Pearson, who was
no enemy of "k"; he changed his own name from Carl and founded the
journal Biometrika. Fans of "k" should promise to write of
mikroekonomics and makroekonomics on the grounds that all the pertinent
roots of those words are all Greek too. See an entire dedicated thread here.
Finally, here is some not yet idiomatic English (prejudices ahead).
The expressions "a data" (to mean a dataset) and "a code" (to mean a
program) are not yet part of standard English. They are already
collectives.
Using "skew" to mean "bias" is unfortunate, but general English usage has shifted strongly that way in recent years.
On the grey area between statistical terms we know (and sometimes love) and uses or abuses of the same words within and beyond statistics and science, see also the thread here.