I'm not really sure if Cargo is the right option, but it's the simplest
alternative I know of to SMW.

Perhaps categories would suffice, if the important stats can be
expressed just as category counts. It sounds like it could get annoying
though.

I do feel a bit like we'd be missing a win if, for the query-able data
in a site about MediaWikis, we were forced to build a custom extension
for doing the querying. It's the sort of thing that lots of wikis want
to do! But maybe it's the best way to go.

Hi,

Sam proposes switching to Cargo. However, from what I've heard (and I
haven't used Cargo myself), Cargo is another beast and comes with its
own problems as well. Someone with more experience with Cargo should
probably assess whether it would be a good idea or not to use Cargo
here. Maybe there's a way to do roughly the same queries by using
categories instead, and the help of one of the available
DynamicPageList extensions.

Best regards,

--
Jesús Martínez
Ciencia Al Poder

My understanding is that the basic structure of Wikiapiary is firstly a
system of templates etc that stores data from the sites' pages into SMW
and then reads it out for various reports; and secondly the scripts that
populate the wikitext pages with data fetched from the sites (and
extensions etc). The really valuable bits to me are the fact of having a
categorized/tagged index to MediaWiki sites, and the extension
popularity info. The first part of that is most valuable as a
human-curated thing, so I think that'd make sense to get back online
even if it wasn't bot-updated. The extension and other site info is
silly to update by hand, but there isn't an absolute reason that the
bots doing the updating need to be part of the WikiApiary
infrastructure, so perhaps if WikiApiary was online, a new system of
fetching site info could be built.

Then, of course, is the separate issue of *how* to store the info on the
wiki. It's SMW at the moment, but it sounds like that hits some resource
issues given the number of queries being run and the amount of data.
Would Cargo be better? I feel like switching to that would be not an
insurmountable thing to do (compared to say moving to Wikibase to store
the data, which would be a bigger restructure). The individual sites'
pages mightn't even need to be changed (if all the storage/querying
logic is in templates and modules).

I vote for bringing it online again now, even if it's without SMW or the
bots, and updating it to the latest MediaWiki. If any of that's possible
of course.

Thank you for working on it! I'm not sure how much time I've got to
help, but I'd love to try.

—Sam

Triple Camera <TripleCamera@outlook.com> wrote:

The database has been locked for half a year, Bots and editors are
waiting, and they are losing patience. I believe the most urgent thing
to do is to make WikiApiary back online as soon as possible.

If we brought WikiApiary back online right now without the bots, would
that be acceptable?

I'm trying to understand what you need from the site and how you've used
it, so any information you have would be useful.

If you or other users of the site can let us know how you would like to
use it, that well help us make sure we are able bring it back online in
as useful a way as possible.

Mark.

Hi Mark,

Sorry, but I don't think rebuilding from scratch is a good idea.
Rewriting the infrastructure that has been running for 10 years is a lot of work.
If you don't have time to resolve problems now, you won't have time to redesign the site either.

Three months ago, you proposed to downgrade WikiApiary to a lower SMW version.
This option seems more feasible.
The database has been locked for half a year, bots and editors are waiting, and they are losing patience.
I believe the most urgent thing to do is to make WikiApiary back online as soon as possible.
So, I suggest that we can downgrade and reopen this site first, and then gradually replace the old infrastructure.

Also, could you share more information about which parts need to be rewritten?

Thanks.

Regards,

TripleCamera2022

Dear fans of WikiApiary,

After a year or more of limping along, we're taking WikiApiary offline
to rebuild the site.

If you use Wikiapiary or have used Wikiapiary, or have written a bot
that uses Wikiapiary, we need your input on the design.

We need the help of volunteers. We have ideas around how to construct
the site so that it is robust, but we'd like input from the community
for its design.

The reimplementation of Wikiapiary is mainly happening because we
couldn't resolve some SMW issues and its query limitations as well as
just the need to update the wiki.

The site has become unmaintainable and those of us who have been
responsible for the back-end (mainly Cindy and myself) haven't had time
to dedicate to resolving the problems

A major contributing factor to this decision is the ongoing cost of
hosting. Previously, we started to move it back to Wikimedia Cloud
Services, but attempted to upgrade it before moving it while keeping the
design the same.

That ended up causing problems which blocked our progress.

As a result, we've decided we need to rethink Wikiapiary's design
completely and rebuild it from scratch.

I'm interested in your feedback and any ideas you may have.

Thanks,

Mark.