Another alternative is that we could add an endpoint in Toolhub that would show whether the edits are from Toolhub or Toolhunt.
I don't know whether it is possible to edit Toolhub
The advantage of this would be that we would not need to have a separate DB and it would just be a request to the Toolhub.
The con is that it is also a lot of work.

With a dedicated database, we could store information about the edits made using the Toolhunt app.

At a minimum, we would need to store the microtasks in a database, and keep them fresh by running a scheduled job. Being able to retrieve per-user edit stats from our own db seems reasonable, although not strictly necessary, as this info can be obtained from Toolhub. On the other hand, nothing prevents us from keeping both current and completed tasks, with completed tasks having some extra info attached such as the user who made the edit and the edit date, as @NicoleLBee mentioned above.

In T324749#8456070, @Hannah_Njoroge wrote:

Another alternative is that we could add an endpoint in Toolhub that would show whether the edits are from Toolhub or Toolhunt.
I don't know whether it is possible to edit Toolhub

This is possible; whether it's worth the effort is a different question, and I don't have an answer right now. My inclination would be to keep things as simple as possible on our side until we have an MVP, then iterate on a better solution if we find the current system too cumbersome.

In T324749#8456083, @Slst2020 wrote:

With a dedicated database, we could store information about the edits made using the Toolhunt app.

At a minimum, we would need to store the microtasks in a database, and keep them fresh by running a scheduled job. Being able to retrieve per-user edit stats from our own db seems reasonable, although not strictly necessary, as this info can be obtained from Toolhub. On the other hand, nothing prevents us from keeping both current and completed tasks, with completed tasks having some extra info attached such as the user who made the edit and the edit date, as @NicoleLBee mentioned above.

Having done some experimentation in PAWS (see T324669), I have some additional comments and thoughts:

• If the goal of the leaderboard is to specifically display edits made using Toolhunt, then we will want to have a way of keeping track of that information. But in terms of presenting a MVP, we could just go with what's available via the Toolhub API and work on a database later.

• The same applies if we want to display information about the most recent edits made (using Toolhunt) on the dashboard. (I know that this is still open to discussion, but if the idea is to present a "gamified" system, it could be fun to let people "scope out the competition" so to speak.)

• When it comes to tracking a specific user's edits, I see no reason not to simply make a request to the /api/auditlogs/ endpoint, using the username as a query string. That could be presented simply as "your most recent edits." (Similarly, "most recent global edits" could be displayed as such, and not explicitly tied to use of the Toolhunt tool. Again, it might be worth just doing it this way when we're building the MVP and worry about accuracy later.)

• If we want to get information about the field that was edited, then there is a *very* roundabout way of doing it using the Toolhunt API that would require us to make a couple of API calls and do some tricky parsing of the data. While it's technically possible, I don't think it's worth it.

In T324749#8456497, @NicoleLBee wrote:

• If the goal of the leaderboard is to specifically display edits made using Toolhunt, then we will want to have a way of keeping track of that information. But in terms of presenting a MVP, we could just go with what's available via the Toolhub API and work on a database later.

When users edit a tool using the Toolhub UI, they have to add a comment before publishing the updated info. The
/api/tools/{name}/ PUT endpoint doesn't enforce this, but we still have the option to do so. A possibility then would be to autogenerate and add a comment to each PUT request in the format "Added <field_name> info via Toolhunt" or similar, before sending it from our backend to Toolhub.

The parsing we'd have to do to filter edits by origin by way of the comments would probably be a bit cumbersome and not very elegant compared to implementing whatever would make our task easier in Toolhub itself, but it's a viable option for an MVP.

In T324749#8456588, @Slst2020 wrote:

In T324749#8456497, @NicoleLBee wrote:

• If the goal of the leaderboard is to specifically display edits made using Toolhunt, then we will want to have a way of keeping track of that information. But in terms of presenting a MVP, we could just go with what's available via the Toolhub API and work on a database later.

When users edit a tool using the Toolhub UI, they have to add a comment before publishing the updated info. The
/api/tools/{name}/ PUT endpoint doesn't enforce this, but we still have the option to do so. A possibility then would be to autogenerate and add a comment to each PUT request in the format "Added <field_name> info via Toolhunt" or similar, before sending it from our backend to Toolhub.

The parsing we'd have to do to filter edits by origin by way of the comments would probably be a bit cumbersome and not very elegant compared to implementing whatever would make our task easier in Toolhub itself, but it's a viable option for an MVP.

Oh, I see now! You'd mentioned the comment field but it hadn't occurred to me how we could use that to track the Toolhunt-related updates.

The only other problem I came across was the difficulty determining which annotations field had been edited, but that is a minor detail.

I think we can safely conclude that, at this stage in development, we don't have any need for a DB.

In T324749#8456083, @Slst2020 wrote:

With a dedicated database, we could store information about the edits made using the Toolhunt app.

At a minimum, we would need to store the microtasks in a database, and keep them fresh by running a scheduled job. [...]

I'd keep this task open for now, as we'll eventually need a db.

In T324749#8459548, @Slst2020 wrote:

In T324749#8456083, @Slst2020 wrote:

With a dedicated database, we could store information about the edits made using the Toolhunt app.

At a minimum, we would need to store the microtasks in a database, and keep them fresh by running a scheduled job. [...]

I'd keep this task open for now, as we'll eventually need a db.

Sure thing!

https://wikitech.wikimedia.org/wiki/Help:Toolforge/Database#User_databases documents the relatively lightweight process of adding a ToolsDB database for a Toolforge tool. This does not solve additional complexity for your local development environments, but it should not be highly difficult to get working for the "production" deployment to Toolforge.

https://wikitech.wikimedia.org/wiki/User:Legoktm/toolforge_library documents a useful helper library for Python that takes care of most of the complexity of using Toolforge database credentials to access ToolsDB (and the Wiki Replicas).