App
App copied to clipboard
Expensify
Explore cleaning up reportIOUS_ collection key
Problem
Coming from this thread, having a separate reportIOUS_ Onyx key seems unnecessary and confusing, since we create a disconnect between data by separating it into multiple different keys.
Why is this important
Keep the code cleaner and less confusing leads to a better and faster development experience
Solution
Explore if killing the reportIOUS_ key makes sense
This issue has not been updated in over 15 days. eroding to Monthly issue.
P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!
![melvin-bot[bot] avatar](https://avatars.githubusercontent.com/in/179547?v=4 "Published by a pub.dev verified publisher"){kind=small}
Triggered auto assignment to @zanyrenney (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.
@zanyrenney this was part of N7: Manual Requests which is currently on hold. That being said, I'd be down to removing the hold and have this done pre Manual Requests so that we can reduce the scope of that project.
I think this should be internal though as it might involve API changes. cc @roryabraham since you showed some interest in working on this.
I definitely feel passionate that we should make this change and agree it doesn't need to be on hold, though it would probably be irresponsible of me to self-assign this right now 😞
Asking because I don't think we should have any un-assigned issues in this repo anymore.
@JmillsExpensify Yes, I unassigned because this is an internal engineering job. What process should I follow for internal issues?
I also see that a bug label was added, but there's nothing wrong with the code. This is just a refactor.
Reassigning @zanyrenney, per the new BZ process we want all issues assigned. Main chore SO is https://stackoverflow.com/c/expensify/questions/14418.
BZ design doc is https://docs.google.com/document/d/14MayFMbP8g43nNnWtqtgKKnCxbmJw3v0zvk5wZaIzBE/edit#heading=h.mnjguil21u0a
@mallenexpensify it's not clear from the link what you're requiring here. I'm OOO today so if this is urgent daily, i'll need to reassign. Please can you clarify?
This really isn't a bug – it's a refactor. Also it needs to be internal because we're changing Onyx data
@JmillsExpensify @mallenexpensify as Rory and I mentioned previously, this is an internal refactor and not a bug. I think that we should unassign the CM and remove the Bug label. Thoughts?
Based on the BZ design doc
If it’s in E/App, the issue will be auto-labeled as Internal and Weekly. This will help make clear to contributors that these issues are not available for them to make proposals on.
So.. I think weekly and NewFeature makes sense. and Zany shouldn't be assigned if it's not a bug.
Gotcha, so this is one of those refactors that is in an in between state, because parts of the Manual Requests fall within API Unchained, and then other parts fall within N7. Is that right?
For what it's worth, I don't think NewFeature is appropriate here, but I'm fine keeping this unassigned for now. I'll file in the N7 project as well for safe keeping.
Gotcha, so this is one of those refactors that is in an in between state, because parts of the Manual Requests fall within API Unchained, and then other parts fall within N7. Is that right?
It was planned to be done with Manual Requests. However, I think there's no need to wait for that and we can go ahead with this refactor.
@luacmartins Given that this requires knowledge of Manual Requests, who do you think would be a good one to pick this up then?
@JmillsExpensify I'd say that a @Gonals @Julesssss @marcaaron @mountiny @roryabraham are good candidates, but I imagine their plates are quite full atm.
Ok cool. This isn't a bug, and it's not strictly part of API Unchained either, so I am going to remove the daily label on this issue. Ultimately I agree, everyone in that list is working on higher value things.
@Gonals not sure what else you're working on, but this could be a good cleanup item if you have any spare bandwidth.
@Gonals not sure what else you're working on, but this could be a good cleanup item if you have any spare bandwidth.
I'm a bit full this week. I'm working on the smartscan dispute handling automation and I also need to implement a Concierge Travel fix that is blocking open booking.
How urgent is this? I'll probably have some more bandwidth next week
How urgent is this? I'll probably have some more bandwidth next week
I think next week is fine, this is not very urgent.
