Change Details

Currently, file revisions are managed separately from revisions of the file description page. That can lead to confusion and inconsistencies not only on the "surface" of user interaction, but also in the internal update and management processes. Evidence: T5498, T2778, T35292, T42178, T589 (this is from a cursory search, there are likely several more). This RFC proposes to integrate the upload history with the file edit history. The RFC should be considered in two parts: //whether// this should be done, and if yes, //how// it should be done. When deciding whether upload and edit history should be combined, numerous edge cases are to be considered: * what does a diff for an upload look like? * how does revision deletion/oversight interact with upload revisions? * how would undo and revert work? * does an edit always change either the file or the text, or can it change both, so data and meta-data can be kept in sync? Also, consider that besides the file data and the description text, in the future we may have a third set of data tied to the revision, namely the structured meta-data for the file, managed using Wikibase. When discussing the //how//, perhaps the notion of having multiple content blobs per page and revision could be helpful. Such "attachments" or "multipart content" has been discussed several times as a mechanism for managing meta-data such as categories outside the wikitext.

Currently, file revisions are managed separately from revisions of the file description page. That can lead to confusion and inconsistencies not only on the "surface" of user interaction, but also in the internal update and management processes. Evidence: T5498, T2778, T35292, T42178, T28741, T589 (this is from a cursory search, there are likely several more). This RFC proposes to integrate the upload history with the file edit history. The RFC should be considered in two parts: //whether// this should be done, and if yes, //how// it should be done. When deciding whether upload and edit history should be combined, numerous edge cases are to be considered: * what does a diff for an upload look like? * how does revision deletion/oversight interact with upload revisions? * how would undo and revert work? * does an edit always change either the file or the text, or can it change both, so data and meta-data can be kept in sync? Also, consider that besides the file data and the description text, in the future we may have a third set of data tied to the revision, namely the structured meta-data for the file, managed using Wikibase. When discussing the //how//, perhaps the notion of having multiple content blobs per page and revision could be helpful. Such "attachments" or "multipart content" has been discussed several times as a mechanism for managing meta-data such as categories outside the wikitext.

Currently, file revisions are managed separately from revisions of the file description page. That can lead to confusion and inconsistencies not only on the "surface" of user interaction, but also in the internal update and management processes. Evidence: T5498, T2778, T35292, T42178, T28741, T589 (this is from a cursory search, there are likely several more). This RFC proposes to integrate the upload history with the file edit history. The RFC should be considered in two parts: //whether// this should be done, and if yes, //how// it should be done. When deciding whether upload and edit history should be combined, numerous edge cases are to be considered: * what does a diff for an upload look like? * how does revision deletion/oversight interact with upload revisions? * how would undo and revert work? * does an edit always change either the file or the text, or can it change both, so data and meta-data can be kept in sync? Also, consider that besides the file data and the description text, in the future we may have a third set of data tied to the revision, namely the structured meta-data for the file, managed using Wikibase. When discussing the //how//, perhaps the notion of having multiple content blobs per page and revision could be helpful. Such "attachments" or "multipart content" has been discussed several times as a mechanism for managing meta-data such as categories outside the wikitext.