Make integrations review process better #1092
Comments
|
And what is the background and why was a separate process for integrations made? |
|
I have no clue, I'm hoping that @jancborchardt can enlighten us. It's a bad system. |
|
@AndyScherzinger @karlitschek @jospoortvliet do you know why this separate process for integrations was established? I agree with @DaphneMuller that it seems strange to have a different flow just for integrations, and it could be easier for everyone (no?) if it is the same as for app developers. |
|
Just discussed this with Frank. The entire feature for these integrations can be deleted. @bigcat88 can you give me an effort estimate please or add it to your to do list it if it is less than 3 days of work? |
|
as a follow up on #1101 It turns out that this integration publishing feature is actively used for publishing clients. This is a good use case and it would be great to have all clients published in the app store, however the way this is designed is totally confusing and it is not obvious at all to client developers that this integrations publishing feature can be used to publish their client. So, the feature cannot be deleted, but has to be redesigned and renamed. @szaimen or anyone else of the design team, @jancborchardt what do you think? |
|
We could rename it to "Mobile & desktop developers"? That is very specific. (Yes it doesn't include other web apps which use Nextcloud though.) |
|
are there other web apps to be included then? @jancborchardt do you have examples of any of those |
And in one word it can be called "Integrations", imho, how it is called now. |
|
@DaphneMuller not many, but e.g. WebEx using our file picker could be an example? (And more if we really push our APIs.) Then it would indeed make more sense to continue ti call it "Integrations" and explain it. |
|
I discussed this a bit with @DaphneMuller since I also wasn't aware of this feature and we came up with this idea:
Note: The register Integration and register Client flow are basically the same, just other wording. I guess in the database they can also stay in the same table, just have a field to tell the App store if it is an Integration or Client. Please let us know your thoughts, we will also discuss this in the next Integrations Team call on Monday. |
as for me it would be ideal if it was one flow, since it is still unclear to me where the external application will eventually go - to the third type of flow?
Fully agree, but then we all need appstore accounts, and probably - administrative ones. Very hard question, we can implement half-admin accounts, but it will take a lot of time.
Can you elaborate what is "The Integrations that are not apps" ?
Problem is that, Client can be an Integration.
This should be done with Tags. We need to think very wide from here, imho, as probably from the next week I will start thinking and implementing support of External Applications in the AppStore, as we already on stage when we are finished prototyping stage.
As an initial idea - not bad, we all need to prepare for a brainstorm. |
|
Having the same flow for normal apps and integrations is going to be hard, IMO, because integrations don't publish their app on the Nextcloud app store, but somewhere else. While we're at it: Integration developers also currently cannot edit these entries. Ever. |
Yeah, that's a major issue. Somehow, I can edit them when reviewing, but then I become the owner for some weird reason.
That is not true, I've approved many dozens of them and rejected many more. It's not working great and shouldn't just rely on me, but there are tons of apps in the store that were created through this process. We do need this for third party integrations, which is why it was developed in the first place - on request of Frank and myself. We wanted a way to display nextcloud clients and third party integrations that have no Nextcloud app or side, like DavX5. Frank might have forgotten about it, it's been a few years, or has never seen what apps are in this category - happy to talk to him about it and remind him. But I'd say, the idea worked and did what it was supposed to do, but the implementation isn't great. Instead of deleting it, how about fixing it? The need hasn't gone away, so if we delete it now, we just have to develop it from scratch later on. BTW in the last weeks, something was changed in the app store, and the integration process is now broken. I've been trying to approve some and they keep publishing weird stuff: meanwhile, some examples of the integrations:
Anyway, after going over half the page I thought I should do something else with my time ;-) Let's fix this, like making it possible to change entries, and letting a team review instead of just me. But don't delete it. Oh and we probably want to make this multiple categories. Right now, nobody scrolls through that list, of course, even if it gives you a page to link to (which is, of course, valuable in itself). |
|
@jospoortvliet we won't remove this feature! We will fix it properly and make it actually useful. We had some discussion about it during our team call but didn't post the results here. Sorry for that. |
Great to hear 🕺🏻 |
So apparently there seems to be a separate system if people want to develop an integration and have it linked in the app store. It is seemingly a different system from the normal app upload process. And it is very inconvenient.
The workflow is as follows:
I think we should figure out which system this is and if we have to keep it, and if we have to keep it, we have to make sure that other people than Jos can approve the integration so that the integrations get reviewed faster.
@jancborchardt @AndyScherzinger please let me know if we have to keep this system
@bigcat88 it would be great if you could provide some details and your opinion on what to do here
The text was updated successfully, but these errors were encountered: