User:Gabinaluz/Modifying Expectations

Original Timeline

Initially, I wrote a detailed timeline for the project (currently in phabricator). However, the week's tasks descriptions had different levels of detail, depending on the depth of knowledge about the topic during the planning phase. Some details were intentionally left abstract, to be refined during the code implementation phase.

The original timeline can be summarized as follows:

Week 1: Research the current method for calculating added references.
Week 2: Having identified the required data for calculating the "references added" feature, investigate the misalignment API to obtain data for the new implementation.
Week 3: Flexible time for adjustments.
Week 4: Evaluate the need for modifications to models to store data from the new API.
Week 5-6: Develop a streamlined method for making requests to the new API.
Week 7-8: Implement a way to use the newly created class to import and store data in the database.
Week 9-10: Integrate all changes.
Week 11-12: Develop a deployment plan for production.
Week 13: Conduct a final performance review with my mentor.

Modifying the schedule

After researching the current method for calculating added references and investigating the existing misalignment API, we decided to update the schedule a bit and build our own API to retrieve number of references from revision ids. Why did we take that path? Well, right after starting the internship, one of the builders of the existing misalignment API reached me to clarify some aspects about it. This involved several points: it turned out that the existing misalignment API was originally designed as a research prototype so it was intended to be eventually removed. Also and more importantly, it was hosted in a shared space where someone could one day delete it unknowingly. Therefore, we concluded that it wasn't a great place for it to exist to sustain the dashboard long-term. In addition, the logic we needed around references was relatively simple and the existing misalignment API was doing a bunch of other things that slow it down or could cause errors.

Because of that, we came up with the idea of building a new reference-counter API hosted in Toolforge. Toolforge will protect against that accidental deletion piece and give wikiedu folks more easy access. Building a new API was also a good opportunity to simplify further so it's easier to maintain, faster, and less likely to fail inexplicably.

Met goals

During the first half of the internship there are some goals that we already achieved. This involves:

The new reference-counter API hosted in Toolforge is already deployed.
A ruby class to make requests to the new API was developed.
A refactoring to some existing ruby classes was done to decouple some functionalities and make easier the use of the new API.

Conclusions

After this month and a half working on this project, I can conclude that making a detailed week-by-week schedule, but with a certain degree of abstraction, was the right decision. Also, discussing it with community members who had valuable background information for the project was very beneficial to improve some approaches.