WikiApiary:Website status flags

Worksheet to explore the various status flags that are required to track websites in WikiApiary.

Secenarios

#	Scenario	Action	Validated	Active	In error
1	Visitor has registered a new wiki	Form:Website is submitted	False	False	False
2a	Operator has verified the site is responding and that the API endpoints return valid JSON	Operator flags as validated	True	False	False
2b	Operator has verified the site is responding and that the API endpoints return valid JSON, but the wiki is inaccessible	Operator flags as activated	False	True	False
3	Operator has activated the site for data collection	Operator flags as activated	True	True	False
4	Bumble Bee has gotten a single error when requesting information	Audit Bee turns in error on	True	True	True
5	Bumble Bee has gotten repeated errors when requesting information	Audit Bee turns activated off	True	False	True
6	Audit Bee has not detected any edits for 12 weeks	Audit Bee turns activated off	True	False	n/a
7	Website DNS no longer resolves, cannot connect	Someone turns validated and active off.	False	False	True

Background

In error

This is used to store the error state of a site in between various bots. A bot will record an error to the talk page of a given site if In error is currently false, and toggle In error to true and set Property:Has error date to the current time. If the site is already known to be in error and a subsequent error occurs, then it will not issue another message to the talk page, but it will increment Property:Has error count and leave Property:Has error date as is. Audit Bee will check sites that are In error for some duration from In error start date and mark them as no longer active. These flags will all be modified using the Semantic Forms autoedit API methods.

Discussion

Is there a role for a Is defunct property? Thingles (talk) 19:31, 27 January 2013 (UTC)

No, since the Is in error property provides more flexibility in usage and would fit perfect into the framework described by you. --[[kgh]] (talk) 12:01, 28 January 2013 (UTC)

It would be really nice to have the timestamp that certain flags were set but it's not easy to get those. Bots could provide the timestamp when they take action. Note the Property:In error and Property:Has error date. Thingles (talk) 19:31, 27 January 2013 (UTC)

If the bot can set a timestamp it will be not different from a human doing so. So it would be ok to let them set the timestamp if they take action. Usually humans only have to intervene if they get a message from the administrator that everything is ok again. I do not think that this will happen in most cases. --[[kgh]] (talk) 12:01, 28 January 2013 (UTC)

It seems like there could be a need for a bot controlled version of Is active that allows human operators and bots to flag things independently and not conflict each other. An example of this might be a wiki that fails several requests and is put to sleep for 24 hours for the next check. This could set a bot controlled active flag to false with another field for the next time to check. Thingles (talk) 19:31, 27 January 2013 (UTC)

Hmm, there should rather be a bot controlled version of In error which would fit better into the framework described above. --[[kgh]] (talk) 12:01, 28 January 2013 (UTC)