Grants:Project/Rapid/Juandev/Accessibility and improvement of VicuñaUploader/Report
- Report accepted
- To read the approved grant submission describing the plan for this project, please visit Grants:Project/Rapid/Juandev/Accessibility and improvement of VicuñaUploader.
- You may still comment on this report on its discussion page, or visit the discussion page to read the discussion about this report.
- You are welcome to Email rapidgrants at wikimedia dot org at any time if you have questions or concerns about this report.
Goals edit
Did you meet your goals? Are you happy with how the project went?
Most of the tasks have been completed, however, because it is live software that is linked to other live software, problems are constantly emerging and need to be worked on.
I am satisfied with the results of the project, but I am not at all pleased that there has not yet been a programmer who would take care of the project on its own. Wikimedia Commons community needs a working standalone mass uploader, as Ranjithsiji explains in this year's "community wishes", otherwise, the activity of individuals, as well as institutions, is declining (see e.g. here). So I'm glad that after last year's outage of three major external upload software, we managed to put at least VicuñaUploader (VU) into operation.
Outcome edit
Please report on your original project targets. Please be sure to review and provide metrics required for Rapid Grants.
| Target outcome | Achieved outcome | Explanation |
| 1 stable release | 5 stable releases | The reason we have released more versions than we were targeting (the original plan was two releases) was, that we wanted to provide Wikimedia Commons users with a working standalone mass upload tool as soon as possible and we wanted to fix bugs as soon as possible. Thus we were not waiting for the cumulation of fixes and we were providing the software as soon as possible. This process was also speeded up. |
| VU work under different platforms (Windows, Linux, Ubuntu, Mac OS) | VU work under Windows and Linux-like operation systems | Functionality under Mac not known. We haven't compiled and tested VU on Mac OS due to the fact, that we don't have this OS, nor have we found a person to test it nor have we found a request from the community pointing out that VU doesn't work on Mac or Mac related issue. |
| no hidden buttons | no hidden buttons | The problem was fixed. |
| files are named in order of their creation | files are named in order of their creation | The problem was fixed. |
| tool for geographical coordinates work properly | tool for geographical coordinates work properly | The problem was fixed. |
| the category name dropdown menu can also be turned on/off using keyboard shortcuts | the category name dropdown menu can also be turned on/off using keyboard shortcuts | The problem was fixed. |
| geo tool can fill also Location template and add direction in which the photograph is made | geo tool adds direction in which the photograph is made | The goal was partially fixed. We haven't added the Location template feature. |
| VU provide feedback to the user on the state of the upload in the window description | VU provide feedback to the user on the state of the upload in the window description | The problem was fixed. |
| 40 (50)* number of users each month in the year after the completion of the project | 11-20 users each month from the release of the first supported version | During the last half of the year between 11-20 unique users were using different versions of the supported edition of VU. Even the end of the year is one of the two seasons which attracts most users two use the software traditionally, we haven't reached set or pre problem numbers of around 40 users. This may be caused, by continuous problems which made even the new version (1.24.8a) hard to use and we had to release other versions. The future, especially the summer and fall of 2022, will show whether our expectation of users coming back to VU after fixing it will happen. This also depends, on whether it will work during the year without major problems *These numbers are heavily influenced by the COVID-19 pandemic. Due to the frequent lockdowns and other problems that contributors may have due to COVID the amount of images is expected to decrease anyway. If the situation regarding COVID-19 gets better we would make targets higher as indicated in the brackets. |
| 15.000 (30.000)* number of files uploaded using the toll per month in the year after the completion of the project | 10.300 on an average of six months from the first release of the development phase | This targeted and its achievement could be commented the same way as the previous one. See above. *These numbers are heavily influenced by the COVID-19 pandemic. Due to the frequent lockdowns and other problems that contributors may have due to COVID the amount of images is expected to decrease anyway. If the situation regarding COVID-19 gets better we would make targets higher as indicated in the brackets. |
Learning edit
Projects do not always go according to plan. Sharing what you learned can help you and others plan similar projects in the future. Help the movement learn from your experience by answering the following questions:
- What worked well?
- Beta-testing worked well. We could be certain that bugs were really fixed, before the official release, but it was time-consuming, and sometimes it was postponing the official release, that we finally decided, that there will be no pre-testing and the release will be tested by the community.
- Also recollection of bugs and enhancement proposals from the community worked well.
- Finally broader scope on looking on the problem, like fixing WikipediaLibrary and including it to VU or including JDK to packs for Windows users, that they don't have trouble installing Java, let us overstep some problems, which would stay unsolved for a very long time and may block us to release usable version at all.
- We also move to track bugs and enhancements in Github, which made the work easier than tracking them in Excell tabs.
- What did not work so well?
- One of the major problems is, that there is no programmer to overtake the maintenance of VU and request the grant for it. So Juandev took a grant and find a programmer to cooperate with. Unfortunately, it was quite a loss of time for Juandev to bridge communication between the community and programmer, the step which would not be needed at all, if there is a programmer, who uses VU (or who at least does bunch uploads to Wikimedia Commons) overtakes VU and communicates directly with the community.
- The second biggest problem was the communication or better to say the cooperation with programmers. The first contacted wiki programme was dismissed due to Wikimedia Foundation's financial rules, that you cannot receive funding on certain activities from both APG and Rapid Grant. The second programmer stopped to communicate and hasn't started the work. That have postpone the start of the project for about half a year and we were not able to fix all problems and enhancements we had wanted. It also led to the conflict on the VU main page and confusion among users, when the first programmer showed up and started to work at VU pushing his releases and himself to the granted project. The first problem was, that he could not be included as paid participant as mentioned above. The second problem was, that Juandev have no expertise to manage more programmers working on the same project. Lastly the fact that the supported edition (SE) automatically updated to the non-supported edition and SE was pushed to unofficial may confuse and discourage the community on which version to use and where to report problems.
- What would you do differently next time?
- In this case the answer is tricky. It took about half a year for Juandev to decide, whether to request the grant. The problems and dangers were obvious. Until this moment wiki programmers were requesting grants themselves because there is no need to create a bridge between community and programmer. So if Juandev adds himself as a bridge between the community and the programmer it would consume quite a lot of his free time, which is not reimbursed. But I am not sure, whether we would have a standalone mass upload tool. We had been looking for a new maintainer of VU for a couple of years asking developers and chapters whether they can overtake it and the answer was no. Once we got the answer yes, the person wanted to be paid for the work but doesn't want to take the grant himself. So this looked like an unnecessary step, but what to do, if there are no parties willing to overtake the crucial tool? This would be easily fixed by developers getting themselves grants as mentioned above.
Finances edit
Grant funds spent edit
Please describe how much grant money you spent for approved expenses, and tell us what you spent it on.
We have spent 28 000 CZK (about 1241 USD) on the programming of VU - i.e. fixing bugs and adding improvements. Some of the bugs and enhancements we provided are mentioned above, moreover, we added new map layers with contour lines and POI to help users to identify easier object position.
Remaining funds edit
Do you have any remaining grant funds?
We have 12058 CZK (about 534 USD) and we would send them back to the Wikimedia Foundation. We believe that the Wikimedia Foundation (as the wish of the community for the mass upload tool was prioritized by WMF positively) will overtake the problem. Meanwhile, we would pay the maintenance from our pockets.
Anything else edit
Anything else you want to share about your project?
Here I would point out the call from both individual and GLAM users to WMF to provide a stand-alone mass upload tool or overtake the existing ones. That would fix many problems for the editing community and our partners, and it would in fact support our goal of increasing the participation, because why we would attract and spend a lot on attracting new participants if we could for much less money stop losing old skilled participants?