On Mon, Nov 25, 2013 at 08:15:44AM +0100, Honza Horak wrote:
I had to express myself un-clearly, because what you're saying is
very similar to what I meant. Having the guidelines simple and
un-ambigous with clear MUST statements was the goal I'd like to
achieve. The rest not-MUSTs could be removed from guidelines entirely
and grouped them under "best practices" section for example.
<nod> So basically reorganization? That sounds good -- although I'm
not
sure about separating Shoulds from Musts. A reorganization that I'd much
rather see is making it easier to see what guidelines are relevant to your
particular package. If I have a python module then I need to read the
Python Guidelines. I also need to read general guidelines about Naming and
Versioning. Proper format of changelogs. Ownership of files and
directories, etc. if my python module does something non-standard (for
instance, built by cmake instead of setuptols) I would need to read the
guidelines around that as well.
In other words, I'd like to reorganize to put everything that you need to
crate and review a type of package together into one place rather than
spreading it out further. Whether that's doable in the wiki, I'm not sure.
it almost seems like a task for a guided wizard -- check all the boxes that
apply to your package and then the wizard assembles the guidelines that may
be relevant to your package. OTOH, I talked to some docs folks way back at
FUDCon Boston and they had some ideas of how to do that in the wiki.... just
never got from the idea stage to a proposal and implementation.
-Toshio