Eternal Return Wiki talk:Community portal

[ Please start new messages at the bottom of the page or click this link to add a new section.]

Adding Cargo and Scribunto to this Wiki
I think adding Cargo and Scribunto would help this wiki a lot, since we could just be editing specific pages (like characters) and have those changes reflect on other pages too, reducing how much work there would be after gameplay patches. Another function that we can script would be item recipes, where we can just mention an item's 2 components and the rest of the tree can be constructed automatically.

Archanist! (talk) 20:16, 20 February 2021 (UTC)
 * I disagree. Cargo/Scribunto is generally only worth the headaches they can cause if you're dealing with larger sets of data, like many hundreds and thousands of something, and you have good reason to provide many lists of the same data using different criteria. This often holds true for CCGs and most MMOs, but not so much for other genres, and I don't see sufficient justification for this game in particular.
 * Essentially, the benefits needs to outweigh these drawbacks:
 * The frequent need to be teaching editors about using purges and null edits to cope with the caching issues in Cargo setups.
 * A wiki with Cargo/Scribunto is always better off having someone comfortable with using a bot such as pywikibot to deal with mass caching issues. Since editors come and go, that's hard to maintain except in super-active communities.
 * The technical bar for editing is raised for certain tasks that tend to come up eventually, such as game mechanic updates that require changing table declarations and cargo queries. Again, you often end up without an editor on hand that understands how to do that when you need one.
 * We also try to discourage this because extensions like Cargo and SMW can cause platform issues for us when a wiki becomes too reliant on them, having them handle too much data or just over-engineering super-complex scripts/templates to handle it. There are wikis that sometimes overwhelm entire database clusters on our network when they make major changes. Once a wiki is that far down the rabbit hole, it's usually very difficult to reverse course, like putting a genie back into the bottle.
 * I simply don't see a case here that the benefits outweigh the long-term risks. These risks would be mitigated if the community here was larger and there would be more chance of retaining editors who can maintain the scripts and Cargo templates, but at the same time, a larger community would have even less reason to do so because it could easily handle the workload of updates with the size of this game's dataset. In smaller wiki communities, I've seen the problems above happen all too often. Usually, that has meant I pick up the slack, but my job responsibilities are changing and it's not clear how much longer I will be this wiki's representative/manager, so this is a particularly awkward time to restructure how this wiki functions. SBEyes (talk) 22:21, 20 February 2021 (UTC)

Oooh, I see what you mean with those points. Would you recommend pywikibot then? Or is manual editing with the community a better option for this wiki? Archanist! (talk) 08:13, 21 February 2021 (UTC)
 * As long as simple manual editing remains an option, there's not really any concern in editors comfortable with using bots doing so as long as they're careful. It would only become a concern if it somehow got to the point where other editors needed to set up pywikibot, because that's something the average editor is likely to struggle with. It's hard to see how you'd end up with that kind of dependency, though. SBEyes (talk) 16:02, 21 February 2021 (UTC)