(2) Information for the users, on how to get in touch with the
developers (community related stuff).
I think it's useful for such basic information as mailing lists to be in
the manual as well, as well as on the web and README. It's important
enough and stable enough that the duplication is outweighed by the
greater visibility, IMHO.
Besides, the manual should certainly describe how to report bugs in the
manual itself, so the address already has to be mentioned.
However, I don't agree to putting the contributor's guide into the
manual,
I hadn't thought about the contrib info. I agree with you about the
technical stuff for bootstrapping, etc., since that stuff can change at
any time and having stale info hanging around in web pages isn't good.
However, once we start talking about all the details of coding
standards, I think it's worth putting in the manual instead (a separate
chapter or even appendix, sure). Simply because I think too-long
plain text files are less likely to get read and comprehended than a
section in a manual, where there is more context. Lots more visibility
(on the web, etc.) in a manual, too.
Anyway, however it ends up is ok with me. It was mainly the other info
that seemed misplaced to me.
- in README.dev for texinfo,
I'll rename it to README-hacking, since that seems to be the modal name,
and is parallel to README-alpha. Reuben and Jose, maybe you'd like to
rename it in Hello and Recutils too?
Thanks,
karl
