Grants:Project/WikiProject X/CollaborationKit MVP/Midpoint
Welcome to this project's midpoint report! This report shares progress and learning from the grantee's first 3 months.
In a few short sentences or bullet points, give the main highlights of what happened with your project so far.
- As the sole developer now actively maintaining and preparing CollaborationKit for deployment, I reviewed the extension extensively and have come to grips with each of its components. Twice.
- CollaborationKit is now more robust: the product now caches more correctly, and the UI components are both more consistent and reliable against upstream changes.
- While more development is needed, we are now much closer to and have a clear path forward toward deployment, should the community agree.
Methods and activities
How have you setup your project, and what work has been completed so far?
Describe how you've setup your experiment or pilot, sharing your key focuses so far and including links to any background research or past learning that has guided your decisions. List and describe the activities you've undertaken as part of your project to this point.
I initially began by hacking at some of the easier-looking/more annoying random bugs just to try to get a feel for the technical side of the project again, as well as trying to update the onwiki hub and documentation from the first round of the project to better reflect the current focus (in particular the migration to developing CollaborationKit as a MediaWiki extension), but then I suffered a concussion and had to basically start over regardless, since not only did this cause significant delays, I also forgot a lot of what I'd done thus far as a result.
Based on the issues I'd been encountering initially, we decided to change the current focus with the project entirely once I recovered, setting aside most of the onwiki stuff entirely to work specifically on the development aspects. We set a specific deployment target and determined the blockers for that, prioritising tasks to include what would be required for users/ops-side, and what would generate too much useless feedback (known issues that, no matter how minor, people would probably bring up a lot/get confused by a lot/whatever), and from there, I dived back into the development itself, tracked on the workboard.
We also investigated the situation in case of a need to undeploy the extension in an absolute worst-case scenario, and what would be required to cleanly convert the pages back to normal content models, either before or after the extension is entirely removed.
What are the results of your project or any experiments you’ve worked on so far?
Please discuss anything you have created or changed (organized, built, grown, etc) as a result of your project to date.
Much development has happened, many bugs resolved, very productive code output:
- Fixes for coding style and technical debt that has accumulated over the past two years
- Improvements to UI clarity
- More robust and skin-agnostic layouts
- Fixes for caching problems, permissions problems, and problems with the caching of permissions problems
From looking into what would be required for a complete, clean undeployment, we found the situation around content model extensions in general to be a bit lacking. Most of the issues lie not with CollaborationKit itself, but with a lack of support in MediaWiki core content handling (T222670, T222672, T222674). Regardless, this will likely need to be resolved at some point in order to effectively move forward here.
Please take some time to update the table in your project finances page. Check that you’ve listed all approved and actual expenditures as instructed. If there are differences between the planned and actual use of funds, please use the column provided there to explain them.
Then, answer the following question here: Have you spent your funds according to plan so far? Please briefly describe any major changes to budget or expenditures that you anticipate for the second half of your project.
To date, I have spent 5000 USD of the budgeted 10000 USD, as expected for the first half of the project. The project delays have not significantly impacted the finances beyond the time at which they were applied, as reflected on the updated timeline.
The best thing about trying something new is that you learn from it. We want to follow in your footsteps and learn along with you, and we want to know that you are taking enough risks to learn something really interesting! Please use the below sections to describe what is working and what you plan to change for the second half of your project.
What are the challenges
What challenges or obstacles have you encountered? What will you do differently going forward? Please list these as short bullet points.
We have encountered two major challenges with this project:
- The project as a whole encompasses many large problems, and this iteration presented a major shift from previous rounds of work and went from a team effort to a single person needing to fulfil all roles: developer, manager, outreach, designer. It was somewhat overwhelming, and the very scope of it hampered productivity simply by nature of its overwhelmingness.
- The codebase is genuinely scary. CollaborationKit touches on several difficult areas of MediaWiki, the ability to work with which some would consider to be unnatural:
- Content and ContentHandler
- Parser and ParserOutput
- EditPage, HTMLForm, and OOUI, together and separately
- SkinTemplate and cross-skin compatibility in general
- Off by one errors.
There isn't a whole lot to be done about the last two as that's just how development often is, but for the first issue, ultimately this was mitigated by bringing in another developer, Jack Phoenix, in an advisory and review capacity, as well as the current adviser, Brian Wolff, taking a much more active role as well, with regular meetings between the three of us. This improved structure, along with the narrowed focus, made a significant difference toward breaking up the project into much more manageable segments.
What is working well
What have you found works best so far? To help spread successful strategies so that they can be of use to others in the movement, rather than writing lots of text here, we'd like you to share your finding in the form of a link to a learning pattern.
- Estimating time and complexity - maybe still not entirely working well, but at least doing a lot better now than we started out
- When things go wrong, just tell people - also applies, per the other project
Next steps and opportunities
What are the next steps and opportunities you’ll be focusing on for the second half of your project? Please list these as short bullet points. If you're considering applying for a 6-month renewal of this grant at the end of your project, please also mention this here.
We now have a clear list of current remaining issues as deployment blockers:
- Language handling issues (T223185, T222981)
- Tracking for metrics: automatically categorise hubs (T223186) and tag CK-related content model changes (T223269)
- More skin-agnostic styles (T214105,T192327) and responsive mf/mobile support (T156130)
- Templates for converting CK content models into legible wikitext (T192329), example projects, user-facing documentation (T223333)
In the meantime, I will also be reaching to discuss and establish an onwiki consensus for testing the extension in order to proceed with the deployment itself once the above blockers are resolved.
From there, deployment followup should proceed as planned: testing, evaluation, and generally resolving all the problems that come up in practice, or at least a prioritised reasonable subset of a fully tracked project.
Another opportunity has also arisen, with the project where it is and two of us going to be at the Prague hackathon this weekend (and the third available online): now that we have some idea what we're doing with this kind of extension, we would like to take what we've learned forward and make a smaller, but technically similar, extension (T220765) using the same framework. Having more such usages in play should also provide more test cases and examples from which to improve and maintain the backend support for all of them, which should prove valuable moving forward.
- Update from the hackathon project (now dubbed 'THICC'): It turns out that MediaWiki core's support for this type of content model usage is worse than we realised, and nobody's maintaining it because all the funded projects are too specific to include implementing anything of the base infrastructure besides what they specifically need. While this is rather poor practice for future proofing features (wider adoption of the base infrastructure normally means lower maintenance overhead overall), there's not really anything we can do about it here as this is probably the least-funded project of the lot.
We’d love to hear any thoughts you have on how the experience of being a grantee has been so far. What is one thing that surprised you, or that you particularly enjoyed from the past 3 months?
I now have a greater understanding why someone might dress up as various core components of MediaWiki for Halloween. I don't know if this is a good thing or not, but it has made me a bit more willing dive into other difficult development areas as well, such as using ResourceLoader directly to better support Timeless' features and reimplement similar functionality that has broken on various third-party MediaWiki projects I help support. -— Isarra ༆ 16:18, 15 May 2019 (UTC)