search

commons-app / apps-android-commons

The Wikimedia Commons Android app allows users to upload pictures from their Android phone/tablet to Wikimedia Commons
https://commons-app.github.io/
Apache License 2.0
1.01k stars 1.19k forks source link

Make prodDebug the default flavor? #3562

Open nicolas-raoul opened 4 years ago

nicolas-raoul commented 4 years ago

The beta server can be useful in some cases, but it does not work as well. With the app now integrated with Wikidata, more and more features do not work on beta. Really most testing should be done on prod (when testing picture upload, using pictures that are acceptable for prod or aborting before real upload).

What do you think about making prodDebug the default flavor, rather than betaDebug? Many newcomers lose time trying to overcome unsolvable problems that only happen on the beta server.

sivaraam commented 4 years ago

I have mixed opinions about this.

Bad side

If we were just going to change the default build flavour to prodDebug and be done with it, I don't think that would be a good idea. That would not be good as we wouldn't have done[1] the responsible job of communicating to the contributors that they can't just upload any random image to the production servers during their testing[1]. If we don't communicate that well then there are chances of contributors (for testing purposes, of course) uploading pictures that do not meet quality requirements of commons[2]. In the worst case, if there are lot of images that don't fall in scope uploaded to the production servers and the Commons community has a hard time dealing with them this might even result in a bad outlook on our app.

Also, at times in the keen interest of quickly testing the change the person might not be patient enough to give an appropriate title, description, categories for the image which are crucial meta information which make the images usable.

Ok. I think that's enough covering the bad side. Let's move on to the good side without further ado :)

Good side

Assuming we communicate well about what images could be uploaded to the production servers and contributors understand it and take it seriously, good images would be uploaded to Commons which would then be used in a lot of places. We would have passively made more users out of contributors, if you know what I mean ;).

That's an ideal case but I'm not how much deviation from the ideal would be acceptable.

Conclusion

These are my mixed opinions about this change. I slightly favor the side of not doing this change to be on the safer side (erring on the side of caution).

IMO, one of the main pre-requisites for this is every contributor who wants to test by uploading images has access to images which fit the scope of the production servers. I'm not sure about how we could assure this but it would be nice if we could do something for this.

Footnotes

[1]: My opinion is that the on-boarding screen would not be enough for this as the use case differs here. As an aside, I wonder how many people have actually read and digested the content of the onboarding screen rather than just swiping through them 🤔 [2]: Some related links

sivaraam commented 4 years ago

Having shared my concerns about this. I also wanted to share some possible alternatives/suggestions. I've tagged the suggestions with the flavors to which they are applicable.

[BETA] Fix the problem with beta?

Can't we just share the feedback about the issues we face with the beta servers to the backend team and get them fixed? This would be a better, right?

[BETA] test-commons.wikimedia.org

There seems to be a test-commons wiki similar to Wikipedia's test wiki. Link to random image in that wiki

Advantages

Disadvantage

One major drawback is the wiki seems to have been provisioned only for temporary testing. The site's home page reads:

The wiki is scheduled to be closed and deleted in December 2019, so don't get too attached to it!

[BETA] Test wikipedia

I really haven't thought this through. So, this might sound like a totally crazy idea. Rather than connecting to the beta version to the beta cluster how about connecting it to the Test Wikipedia? Yeah, I did say Test Wikipedia. I'm not sure what kind of problems we might face if we do this. But I read this in the Commons FAQ:

Does Commons use a special wiki engine? No. It is the same MediaWiki as for most other Wikimedia sites, but with galleries instead of articles in the main namespace (see the question above). But this site has many heavily customized gadgets and most templates are unique to Commons and developed locally.

So, I had a hunch that this should be feasible.

Advantages

Disadvantages

[PROD] Test images category

There seems to be a separate category to upload test images in Commons. The images uploaded there are subject to deletion without notice, though.

We can make prodDebug the default but ensure all images uploaded fall under the test images category.

[PROD] Use additional tag for prodDebug edits

We can make prodDebug the default but additionally tag any edits made using prodDebug to easily distinguish them. As an aside, the curious reader could have observed the following:

Just to be clear, the "[PROD]" suggestions only apply for the prodDebug variant and not for the prodRelease variant. I hope we can distinguish the debug variant from the release variant during run-time. Correct me if we cannot.

macgills commented 4 years ago

I am massively in favour of a functional beta environment however that materialises, having to use prod to test is not desirable to me at all

Ayan-10 commented 3 years ago

@nicolas-raoul @sivaraam @macgills I think instead of making the prod default. We can fix certain cases where beta is not working because it's next to impossible for a contributor to every time post something meaningful while testing and making the prod default branch can lead to lots of unnecessary media on the production server. I recently faced these kinds of issues in beta. I think these issues are very less. So we can fix those issues one by one.

Some issues are occurring because we are using https://commons.wikimedia.beta.wmflabs.org this URL in the beta branch, this URL is not giving any response for some of the GET calls. What if we use https://commons.wikimedia.org this URL in those particular places? We are not doing POST calls, So I guess any GET operation will not harm the production server. Like these, we can solve all of the issues.

Please let me know your thoughts on this.

sivaraam commented 3 years ago

Some issues are occurring because we are using https://commons.wikimedia.beta.wmflabs.org this URL in the beta branch, this URL is not giving any response for some of the GET calls. What if we use https://commons.wikimedia.org this URL in those particular places? We are not doing POST calls, So I guess any GET operation will not harm the production server. Like these, we can solve all of the issues.

Interesting. We couldn't have just possibly gotten away with GET operations to the production server in all places. The main feature of the app revolves around uploading media to Commons which would need some kind of POST, PUT call etc.

Are you trying to suggest we should use the production server for GET calls alone and the beta server for data POST/PUT level things? Does this really help with making beta more usable? 🤔

Ayan-10 commented 3 years ago

@sivaraam Yes, We can't POST to the production server from beta. but some features of the app don't work at all in the beta version. I found out some problems which are related to fetch operation in the beta server (Related to Wikidata). As there is no harm in using the production server for the GET calls, for such non-working cases in beta this solution can solve the problem.

I am not talking about everywhere using the production server for GET calls in beta. I am saying just for such cases where the beta server is not giving any response for the GET calls. We can use the production server for the GET calls.

sivaraam commented 3 years ago

I am not talking about everywhere using the production server for GET calls in beta. I am saying just for such cases where the beta server is not giving any response for the GET calls. We can use the production server for the GET calls.

Even though querying the production server only for certain things might seem to solve the issue on the surface, it would likely not solve the problem. You could take the wikidata issue for instance. Structured Data for Commons doesn't work properly in the beta server in some cases. But querying the production server only for the cases in which the requests fail would not work because the image for which you would be sending the query might not be present in the production server or might be present with a different name.

Further, using the beta server for some parts of the app while using the production server for others might also result in a more confusing/convoluted experience during development. One would have to remember parts/features of the beta flavour app query the beta server and which parts/features query the production server. It's better if we stick to using one server per flavour to keep things simple.

We could also hear what others think. cc @nicolas-raoul @misaochan

misaochan commented 3 years ago

I agree, the beta and production servers need to be kept separate.

I'm honestly on the fence re: which build flavour to use as the default. On the one hand, the majority of the issues described here for the beta cluster (e.g. Wikidata fetch) can be solved by simply using prod as the flavour for such operations - there is no need to upload a picture to test Wikidata fetch, so there is no reason to use the beta cluster for it. Personally I use prod unless I know I will be uploading a large number of pictures for testing (which is actually pretty specific, usually related to major upload logic changes. For almost everything else, the upload can be cancelled before uploading.)

On the other hand, it's true that we cannot expect our devs to always be familiar with Commons rules, and this could lead to people being banned (and a bad rep) if we use prod as the default without communication. Prod did in fact use to be the default for several years, but we had far fewer volunteer devs then.

Basically, as long as they are kept separate and documented appropriately, I can see pros and cons to each.

sivaraam commented 3 years ago

I had a crazy thought. In case we show a special pop-up or screen of sorts during installation that communicates to volunteer devs that the prodDebug should not be used for test uploads and that they should betaDebug instead, would it be possible that we could make prodDebug the default? Would that possibly avoid the pitfalls of making it the default as we've warned them during installation?

I haven't given much thought so I'm not even sure how feasible this is. So, apologies if this isn't feasible. Just thought of suggesting this 🙂

misaochan commented 3 years ago

Doable for the debug build flavour, but it would increase complexity, so not sure if it is worth it IMO. :)

Rishavgupta12345 commented 2 years ago

@nicolas-raoul i think this issue is not relevant anymore and we can close this

sivaraam commented 2 years ago

@nicolas-raoul i think this issue is not relevant anymore and we can close this

This one is still relevant as the status of the Commons beta cluster hasn't changed much since the issue was first opened. For more information read the issue description.