Changes between Initial Version and Version 1 of Ticket #4900, comment 9
- Timestamp:
- 12/16/2019 08:57:22 AM (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #4900, comment 9
initial v1 3 3 1) Why would we deliberately choose not to fix a fault on wordpress.org, simply because it's a fault with/in WordPress? There are a thousand other scenarios where dot org diverts from / improves on WP core behaviours. Unless there's a specific reason that we ''can't'' fix it here, I challenge that distinction. 4 4 5 2) It's completely unrealistic to expect a core solution to this. Our problem/solution is simple, contained, and constrained. A solution in core would need to account for myriad other factors, and, core's canonical URL mechanisms are n't laughably unsophisticated. We'd be looking at ''years'' of shoring up basic capabilities before we could even _start_on housekeeping fixes.5 2) It's completely unrealistic to expect a core solution to this. Our problem/solution is simple, contained, and constrained. A solution in core would need to account for myriad other factors, and, core's canonical URL mechanisms are laughably unsophisticated. We'd be looking at ''years'' of shoring up basic capabilities before we could even ''start'' on housekeeping fixes. 6 6 7 7 3) We don't have data on the expected impact, nor will we have isolatable data on the impact of it. That's not how this works. For a start, we're not A/B testing our changes, so there's no baseline to compare against. We're also deep in a position where we're still fixing a million tiny broken things, attempting to put our a raging fire - until we put the fire out, we'll struggle to meaningfully assess the position/performance of the site. In lieu of such data, I'd appreciate you assuming that my expertise and experience is sufficient to have determined that the effort/reward ratio for this fix is worthwhile; at least, it might have been, until we spent an hour bickering about it instead of just fixing it.