Tue, May 15
@Dbrant is going to write a script to see if he can break the service by adding pages from every project that the app supports.
Mon, May 14
@Pchelolo do you have any other objections or were you just looking to resume schemas for consistency?
Fri, May 11
Tue, May 8
Mon, May 7
Tue, May 1
thanks all… we will keep this open and look into it again after we get the code base split up as @bearND suggests
Just a thought on the overloaded field...
Mon, Apr 30
Adding @Lydia_Pintscher for visibility
Fri, Apr 27
Apr 18 2018
@bearND are we good to close this?
FYI I moved this to the kanban board to do column, but you don't have to do this before other work, just wanted to resolve the open question
All of these solutions are fine with me…
As far as suggestions, either per project or an aggregate end point both work for me.
Apr 17 2018
@Mholloway The part I'm not sure about is that this seems to be implicit. -1 and -2 does not clearly mean "non-editible" without knowledge of Parsoid's/MCS's business logic
Apr 9 2018
Bikesheding… I'll be more disciplined about opening tickets
@Mholloway has this been addressed in your Media API work
Just handling this in the thumb API
Very open ended and not actionable. If we want to reopen, lets make a specific ticket to implement.
@bearND is this still an issue?
Also do we maintain it?
@bearND is this within the MCS codebase or separate?
Apr 4 2018
@Mhurd yes, prioritize this over the references!
Apr 3 2018
Apr 2 2018
I get that it’s in a different hierarchy but it’s odd to have the only api that delivers media not under the media hierarchy.
How about just site/css?
Sorry for coming in late here. But I do have an objection with using media. We have another api named media so that’s kind of confusing
Mar 28 2018
Mar 26 2018
I'm going to do research on this in the near term to figure out what the path forward is
So is this something we should address in the PCS @bearND
Is this in references to the Summary service? Or mobile sections?
Mar 23 2018
For context: We have lots of client code with work arounds for getting the right sizes of images. So much duplication and bugs. We want to get rid of this code in the client and instead use this much more flexible proposed API.
@kchapman we are interested in picking this up in Reading Infrastructure, but haven't been able to get to it. We would still like to do this if we can find some time… I should know more in Q4 about feasibility/timing.
@bearND this is a new survey for the Android app only Beta. Can you hop on this on Monday?
Mar 22 2018
Mar 21 2018
Removing type seems fine to me. For the content at the bottom of the page (categories and navlist) are you suggesting we just leave them in becuase they are invisible?
Mar 20 2018
Per the discussion on the ticket and at an RI meeting, we are going to decline this.
Approving this from the management side. Let me know for you need anything else
Mar 19 2018
@Jdlrobson if this is done in the new summary API are we good here?
Yes, we would want to add an additional HTML field (instead of adding HTML to the text field)
@Tgr I'm having trouble figuring out what is actionable on this ticket. Can you explain or update the description to describe the work we need to do (Also I assume you think this falls on RI, correct?)