Merge best practices as "special sections" with rule book

[gryphonshafer]

We have the ability to include arbitrary "special sections" in the rule book that can be filtered during build. An example is "Logic", which contains English-Script that few will want included and which won't be included in standard builds.

I think it'll be a good idea to consider merging best practices into the rule book in a series of "Best Practice" special sections.

[kclimenhaga]

Another possibility would be to have "Best Practices" as endnotes. If we end up with a lot of best practices, it might be too wordy to have them inline, but I agree that a separate document would likely end up being ignored.

[jswingle]

Agreed with @kclimenhaga - the whole point of BPs is that we really want people to read them, even if they're not something that's challengeable. Making them as visible as possible is a good thing. Perhaps we could push for a rulebook render that is most useful for captains/coaches, and another render which emphasizes the BPs that is pushed on officials and question writers/editors?

[gryphonshafer]

Just as an FYI: When things are written under those "magic" section headings, we can "publish" renders of the rule book in a variety of ways. Obviously, we can filter magic sections. But we can also gather up all magic sections of a type and stuff the content at the end (like we do with terms/definitions in the reference render). And if you want to add additional magic sections headings, I can do that easily also.

All that said, if you do want some inline magic sections to become endnotes in some renders and remain inline in others, you have to be careful about how the content is written. For terms/definitions, this is not an issue, of course. But for something like a BP, it would likely need to have a brief introduction so that when it's an endnote, the reader can understand context. But the intro would need to be minimalistic, otherwise it might read slightly weird inline.

[jswingle]

@gryphonshafer I think this is the kind of issue which the Rules Committee doesn't even need to vote on. It's just a tech implementation and the work would need to be done on your end. The RC should vote on what the Best Practices themselves are.

[gryphonshafer]

To accomplish this, there's a technical component (though extremely simple) and a more time-consuming "actually migrate the textual content" task.

For the technical component, if you want best practices to be integrated "special sections" in the document, then you only need to add or alter the builds section of the YAML configuration file. If you want the best practices to be a single section at the end, you can accomplish this the same way.

The "actually migrate textual content" would be something the RC should do.

[jswingle]

I think the right next step would be for the RC to take a vote on how they would like this content included, and then we can figure out the details from there. I would be in favor of the endnote formatting, for the reasons @kclimenhaga has already stated. A separate document would get ignored, but I also want a clear delineation between what is actually a challengeable/protestable rule and what is simply expected and usual.

[jswingle]

@gryphonshafer @josiah-leinbach @kclimenhaga

I think we should continue to consider this issue, but I would like to more or less finalize a Best Practices document BEFORE we consider its implementation. That is a long way off, so I've assigned this to the "Backburner" tag for now. Agree/disagree?