Thread:Talk:Requests for comment/New sites system/First-class data or index/reply (3)

Note that if we get the web UI out and make it the recommended method the site table will quickly turn into something that is always treated as an index.

I don't understand this. Are you talking about what will happen for Wikipedia, or for MediaWiki installs in general? For the later I really don't see how having an edit UI really affects the table being an index or not.

This web UI is actually probably going to end up used for editing the local stuff even when you're using something like Wikidata to fill it.

I don't understand this either - do you mean it could behave incorrectly here if the below is not implemented at all?

How about instead of making it a firstclass/index boolean we call it a 'source'. If the source is the string that the web UI uses it knows that it can edit the global data since it inserted it. If the source is something like 'wikidata' then it knows that it can't edit it and must only let the user modify the local data that it manages.

I'd prefer having settings such as:


 * site data = one of ( primary, editable index, non-editable index )
 * site config = one of ( primary, editable index, non-editable index )

This way the UI is not forced to care about which source it's actually coming from, and the logic to determine if it should allow editing remains in the site interface, which is IMO where it should be (since you can obviously have many editing UIs, APIs, ect).

put source as a column in the database

Sure. This will work if only the site data can come from an external source. If we also want to allow this for the config, we need a second field. So what would you suggest doing? Add site_source, add site_data_source and site_config_source, or something else?