Reading/Web/Preference Persistence For Anonymous Users/TDF Feedback

Timestamp	Email Address	1) Which team(s) are you representing?	2) The Opportunity Statement is clearly defined. [Select One]	3) I understand the scope of the Opportunity Statement. [Select One]	4) It is clear to me what is the problem the team is solving. [Select One]	5) What questions or feedback do you have regarding the Opportunity Statement (the "WHAT" section)?	6) It is clear that the proposed solution will support organizational goals [Select 1]	7) The Opportunity Statement connection to our goals is clear. [Select 1]	8) I am familiar with the goal(s) listed. [Select 1]	9) What questions or feedback do you have regarding the Organizational and User Value (the "WHY" section)?	Will your team(s) be doing any of the work? If so, please share the details.	Will your team(s) be affected by this project immediately or in the future? Please share how.	Will your team(s) desire to be kept in the loop on this project? Please share why or why not.
4/5/2023 11:18:21	jforrester@wikimedia.org	Abstract Wikipedia team	Agree	Agree	Agree	The "impact to movement" doesn't describe any impact on the movement, merely how a team will be able to implement an internal objective of the Foundation. Can it instead / as well be expressed in what is (and is not) going to change about the Wikimedia movement at large because of this? How many more readers will we have? How much more will they read? How more satisfied will they be? How much more pervasive / dependable will Wikimedia content become? Etc. This would steer the input to the design of a system to support these needs. Re. "scope", the "on-wiki storage" section probably (?) means on-server storage, rather than the implication of editing a public world-facing page inside MediaWiki (and theoretically subject to modification by power users for other users); if this could be tweaked to confirm which meaning is intended, that would allay some concerns. An outcome of this work probably should also be a clear process for sign-off on features being allowed or not to use this system, so that e.g. volunteer-written features are not left in limbo, or overly-keen teams swamp the site performance requirements; there should be a designated performance owner of the read experience (most obviously, the Web team's PM) who can agree or reject proposals.	Strongly Agree	Strongly Agree	Strongly Agree	-	No.	Indirect impact on our work.	Happy to be merely Informed.
4/7/2023 13:11:32	rtnf141@gmail.com	Technical Decision Forum Representative	Strongly Agree	Strongly Agree	Strongly Agree	-	Strongly Agree	Strongly Agree	Strongly Agree	Really good idea.	No	No	No
4/10/2023 16:08:13	bdavis@wikimedia.org	Technical Engagement; Developer Advocacy; Wikimedia Cloud Services	Agree	Agree	Neutral	The problem statement does not meet the "using layperson’s terminology" test set out in the criteria in my mind due to various references to "WE2.1". This is not only insider jargon, but also a reference to a bit of data that only exists on the private officewiki environment which is inaccessible to all volunteers. The text of WE2.1 seems to have changed from the time this statement was drafted which also makes the clarity of the problem statement dubious. As of 2023-04-10T20:04Z KR WE2.1 reads "Ensure a quality reading experience for all users by adapting the default experience for X% of pageviews, based on the individual needs and constraints of the user." This does not match the opportunity statement content.	Disagree	Disagree	Disagree	The text of WE2.1 seems to have changed from the time this statement was drafted which also makes the connection of the problem statement to goals dubious. As of 2023-04-10T20:04Z KR WE2.1 reads "Ensure a quality reading experience for all users by adapting the default experience for X% of pageviews, based on the individual needs and constraints of the user." This does not match the opportunity statement content.	No	Developer Advocacy may be asked to help communicate changes to the technical community	Developer Advocacy may be asked to help communicate changes to the technical community
4/11/2023 9:17:17	dcausse@wikimedia.org	Search Platform	Strongly Agree	Agree	Strongly Agree	Missing some clarity on how this storage will compete/complement with Special:Preferences when e.g. an anonymous user who customized their experience creates a new account.	Strongly Agree	Strongly Agree	Agree	Would benefit listing a few of the use cases where the web team was approached by other teams willing to persist some preferences.	No	No	No
4/11/2023 11:25:48	aotto@wikimedia.org	Data Engineering	Strongly Agree	Strongly Agree	Strongly Agree	none	Strongly Agree	Strongly Agree	Strongly Agree	none		no	I don't think so. As long as this does not change the way webrequests and instrumentation are actually handled, we don't need to be informed. IIUC, the changes will be all client side code.
4/12/2023 11:20:36	thiemo.kreuz@wikimedia.de	Wikimedia Deutschland Technical Wishes	Agree	Agree	Neutral	To be honest I don't understand why we don't use the web standard that was specifically designed for this: localStorage. Why do we need to store anything on our servers? What the document talks about appears to be surprisingly over-engineered. Especially for the few rather trivial examples given: Boolean flags like "TOC pinned" or "full width" belong to localStorage, plus a single line of JavaScript to apply it during page load. There is no need to do anything "before the page loads" in these cases. I understand it might be not that trivial for something like dark mode. This should be discussed separately: A) Persisting choices the user made while the page was loaded, e.g. collapsing/expanding page elements, full width and such. These options already exist. They don't require a reload. They just don't persist. B) Preferences that require a reload (e.g. dark mode).	Agree	Neutral	Strongly Agree	Why is it phrased as if this will be internal to the WMF? As far as I understand whatever we come up with needs to be part of MediaWiki, and will be available and possibly relevant for everybody because of this.	We will certainly have (trivial) use-cases that can benefit from this. But we will probably not be involved in setting it up.	Probably yes, in the far future, in probably trivial, non-disruptive ways.	Yes, please.
4/12/2023 20:57:14	bdziewonski@wikimedia.org	Editing	Strongly Agree	Strongly Agree	Strongly Agree	-	Strongly Agree	Strongly Agree	Strongly Agree	-	No	No	No
4/13/2023 7:16:53	mequanint.yehuala@gmail.com	Academia	Strongly Agree	Strongly Agree	Strongly Agree	--	Strongly Agree	Strongly Agree	Strongly Agree	--		yes	no
4/13/2023 16:11:11	gtisza@wikimedia.org	Growth	Neutral	Agree	Strongly Agree	An explanation of the use case instead of a KR reference would have been nice, although it's not hard to guess. "On-wiki storage" is very misleading terminology - I assume what's meant is that the settings will be stored by the browser/device but will be specific to the wiki (domain).	Strongly Agree	Strongly Agree	Strongly Agree	-	no	no	no
4/13/2023 18:27:35	jwang@wikimedia.org	Product Analytics	Strongly Agree	Strongly Agree	Strongly Agree	NA	Strongly Agree	Strongly Agree	Agree	I was confused with "the default experience" in WE2.1 and the customized experience this project will provide. Appreciate more clarification on how this project will impact the X% in WE2.1, increase or decrease?	If needed, product analytics team will help measure the impact of this project in supporting the KR WE2.1.	No, as far as we know.	Yes. As mentioned above, if needed, product analytics team will help measure the effectiveness of this project in supporting the achievement of KR WE2.1.
4/14/2023 6:21:08	apatro@wikimedia.org	Language Engineering Team	Strongly Agree	Agree	Strongly Agree	The scope of what is covered and and not covered may need more thought. For example, how would we handle the case of an anonymous user logging in, and then logging out. Which preference would take precedence?	Strongly Agree	Strongly Agree	Strongly Agree	No.	I do not think that our team will be involved in any of the development.	Our products - Translate and ContentTranslation would potentially use the system that is developed.	We would like to be kept in the loop as our products would be using the persistence for storing anonymous user's editing (not "reading" necessarily) preferences.
4/14/2023 14:41:21	dbredemeyer@wikimedia.org	System Architecture	Strongly Agree	Strongly Agree	Strongly Agree	Do you anticipate multiple users using the same device? Does it matter that one user may customize a wiki, and other users don't know of the mechanism which is now over riding system settings? Will you indicate when system settings are being over ridden?	Strongly Agree	Strongly Agree	Strongly Agree	none	No.	No.	In the What section, you mention identifying a class of related problems, and solving them together. I'm interested in what the related problems are.
4/14/2023 18:21:11	cwhite@wikimedia.org	SRE Observability	Agree	Agree	Agree	None	Agree	Agree	Agree	None	SRE Observability does not have a role to fill in this project.	SRE Observability is not likely to be affected.	SRE Observability does not need regular updates.
4/16/2023 19:48:08	sbassett@wikimedia.org	Security Team	Agree	Agree	Agree	No feedback at this time.	Agree	Agree	Agree	No feedback at this time.	Likely security-related reviews of new code, architecture.	Likely not in the immediate future, unless there were security concerns which needed to be threat-modeled. Though I'm not sure that's really the case here, other than, perhaps how multiple factors might be used to determine a "specific" user.	Sure.
4/18/2023 11:28:11	lgaulia@wikimedia.org	Performance	Neutral	Neutral	Neutral	-	Neutral	Neutral	Strongly Disagree	-	No	Users in countries where google web vitals is already non-satisfactory will be disproportionally impacted due to a further degradation of their experience in favor of customization.	No
4/28/2023 14:20:03	rkattouw@wikimedia.org	Design Systems	Agree	Agree	Agree		Agree	Agree	Agree		No	Not immediately. We may be indirectly affected in the future if this infrastructure is used to toggle things that would affect how Codex components need to look, like dark mode or font size changes	The Design Systems Team works on a fair amount of shared front-end infrastructure. This particular project is not one that we'll work on directly, but it is shared front-end infrastructure and may interact with things we work on now or in the future, so we want to stay informed.