Talk:Beta
Contents
Good information section
the 'good information' section criteria needs from adjustments. several of the canyons listed don't have actual beta. Skelley (talk) 13:30, 11 March 2014 (PDT)
The current criteria for "good information" (visible if you click Edit on the Beta page) are
- Has a KML map
- Is explored (the person writing the information has direct knowledge of the information and didn't just get it from a map or estimates from scouting)
- Specifies the number of rappels and longest rappel
- Has coordinates so it can be labeled on a map
- Has a complete ACA rating (technical, water, time)
- Specifies how long the total hiking distance is
There are two reasons for these criteria and not any requirements on the introduction, approach, descent, etc: personal and programmatic. The personal reason is that I feel like the above information is usually sufficient to actually go and do a canyon myself. More information is nicer, but this is what I feel is necessary to be confident in successfully completing the canyon with the anticipated amount of time, energy, and gear. The programmatic reason is that it's hard to parse page content to determine what sections have content and which don't -- there's nothing special about the different sections of beta pages; they're just wikitext. The numbers specified in the Canyon template (the stuff displayed in the infobox) are special and can be easily processed. I know this probably isn't the most ideal situation, but the purpose of the "good information" section is just to help viewers dive into the content of the wiki -- I don't think it matters all that much if all the pages are of excellent quality (even though of course we'd like them to be) just as long as that list gives people a springboard to find some useful content. But of course I'm open to suggestions on how to change stuff, and you can even do it yourself if you want -- that's what makes wikis awesome :)
Finally, one side note: to sign a message, just add four tildes (~) in a row at the end of the message. The result is this: Bjp (talk) 12:52, 11 March 2014 (PDT)
thanks for the sig tip. I've not used mediawiki in a while. I kinda miss it ... Skelley (talk) 13:30, 11 March 2014 (PDT)
Standardize bearing acronyms
Would be good to agree on bearing acronyms to ease comprehension and avoid confusion for visitors new to canyoneering.
Currently DCL/LDC/"canyon left" and DCR/RDC/"canyon right" are used interchangeably throughout this wiki.
—Bahman (talk) 17:04, 9 May 2014 (PDT)
- "Canyon right" and "canyon left" are used by Chris Brennen and Tom Jones. Bluugnome uses RDC/LDC. Shane Burrows just uses "right" and "left", often with a cardinal direction in parentheses. I'm guessing DCR is an abbreviation of Brenne's "canyon right", plus an additional descriptor to make the side more clear. I recommend RDC because the R is the important thing (and it comes first), RDC is much shorter to type and read then "canyon right", and "DC" unambiguously identifies which of the canyon's rights is being referred to. But, I don't think we need to change existing content until there is a general consensus, which would be indicated by most people using the same convention. For now, I think just adding a link to the Glossary like this (LDC) is fine. Bjp (talk) 12:59, 11 May 2014 (PDT)
Something to keep in mind: The Sierra Canyons beta uses LDC as "Looking Down Canyon". I've been thrown off once or twice due to this. A. Anderson (talk) 21:27, 27 August 2014 (PDT)
I'm leaning towards changing everything as Ben mentioned above: "LDC" and "RDC" as the direction is first and will probably be a good standard in the long run once everything is being written this way. Just watch out for that Sierra Canyon beta until it all gets converted. Also if someone is copy-pasting the Sierra Canyon beta into ropewiki under that account, it would be highly advisable to change it right then to avoid confusion. A. Anderson (talk) 11:04, 28 August 2014 (PDT)
Shuttle time units
I assume that shuttle time is meant to be in minutes. Can we add that unit to the canyon template so that it is automatically displayed, similar to how the hours unit is appended to the 'typical time' data? —Bahman (talk) 13:50, 14 May 2014 (PDT)
Using Categories for Beta
What do people think about adding a Region Names as Categories to Canyon Pages? This would allow us to use the native Category Feature to browse canyons by region more efficiently. Then we can either trasclude or link the native category listing page to the region page.
In theory, this should be achievable by running a simple script. I would do it myself, but it would be a lot easier with access to the file system, rather than using some browser automation tool. Ihiromi (talk) 16:42, 16 May 2014 (PDT)
- It's a cool idea, but do you see this as only a beta site in the end game? Does its usefulness it outweigh our ability to use categories for training, incidents, techniques, equipment, etc? Mediawiki noob, so I'm honestly asking. Dangel (talk) 21:32, 16 May 2014 (PDT)
- I'm not sure what we would gain by making that change. Canyons are already placed in category-like pages called Regions which have special canyon-indexing functionality. Why would one want to go to the Big Tujunga category page rather than the Big Tujunga region page? Moreover, why would we want to have two pages (Big Tujunga category page and Big Tujunga region page) that seem to serve the same purpose? Or alternately, what would making every Region page also be a Category page enable us to do that we can't do now? On a standard MediaWiki installation, it would probably be important to put individual content pages into group category pages like that to enable discovery. But, because we have semantic extensions, that allows us to make even cooler and fancier content indexing and discovery. Basically, I don't understand how using the native Category feature to browse canyons is more efficient than using the semantically-built Region feature -- it seems like the reverse is true, and additionally using the native Category feature doesn't seem to add any functionality. --Bjp (talk) 11:47, 19 May 2014 (PDT)
- After reading up more on semantic mediawiki (I only had experience in the normal flavor, and it took me a while to figure out what was going on in the semantic extensions and templates), I completely agree with you. My only feedback was that the display format wasn't quite up to my standards, and I had started to look at ways of improving it. However, as of today, Lucach just committed a awesome update to the template, which basically entirely covers the expansion that I was planning on. I'm really happy about the current state, and hopefully I'll find another project to work on to improve the UI of the site! --Ihiromi (talk) 17:51, 22 May 2014 (PDT)
- Cool, sounds good. With hindsight, I may have made all Regions categories if I had known about subcategories, but I'm still a little on the fence with the many-to-many relationship and the fact that they have to be in a different namespace. But regardless, we're definitely hardening the current structure. If you're looking for UI improvements, we'd love to reskin things. CC is beating us out in prettiness right now and I don't really have the ascetic sense to do anything about that :) Also yeah, Semantics is some pretty cool stuff. It really brings MediaWiki to a whole new level. --Bjp (talk) 20:34, 22 May 2014 (PDT)
