Hello everyone. As you know Kiwi TCMS has been around for a while and it has
gone through some big changes in the last year! It started as an abandoned
Django 1.6 project with broken test suite and is now currently running on the
latest Django 2.0.1 with Python 3.5! It is clearly a legacy code base!
We, the Kiwi TCMS team, have learned a lot more about the project and this
blog post describes our roadmap for 2018 in terms of technical work and community
engagement. The general technical direction is cleaner/simpler code,
improved UI/UX and more tests!
Make code easier to maintain
The current code is a bunch of very large modules and functions and classes
bundled together. It is also old and sometimes looks like spaghetti code.
CodeClimate gives us a "D" rating
for maintainability with a 1 year estimated effort to fix that. There are 600+
code smells and 600+ duplications detected by CodeClimate. Our goal is to get this
number down to zero!
Use pylint and pylint-django
pylint is the standard static analyzer for Python and currently it reports over
4000 errors and warnings when executed against Kiwi TCMS. This is a huge number and
it needs to become zero! We've also identified interesting patterns that will
make it into pylint and pylint-django plugins!
Render HTML, return JSON
The current state of affairs is a mix and match of everything. There are views that
render HTML, others which return pure JSON, other which return HTML encoded as JSON string
and probably everything in between. Views that render pages need to do just that
and views that are used with AJAX calls from the UI need to return pure JSON!
A lot of these are hiding in plain sight and will come to light when we start
overhauling the user interface.
Submit forms, post JSON, GET clean URLs
There are lots of forms in Kiwi TCMS. Sometimes they are submitted by the user and
other times they are serialized and POSTed by some JavaScript code. This isn't
very easy to understand plus this entire home-grown utility code doesn't bring
anything useful to the project. All of these need to be identified and cleaned up.
JavaScript code needs to send or consume JSON, nothing else!
There are also lots of places where Kiwi issues GET requests with a number of
query parameters. Our goal is to minimize these and where possible have the
parameters as part of the Django urls scheme, not as query strings.
API layer
The current API module is a bit disorganized. API namespaces don't match the
names of the underlying DB models and the API client classes don't match any
of the other two! The way we pass parameters and what these parameters are
named should match between the client, the RPC method and the underlying model!
In earlier releases we've removed duplicate or similar RPC methods and we
think there are more of these that need our love.
Documentation
We've started producing documentation from doc-strings and most of the RPC
methods have such. However it is unformatted and barely readable, sometimes
even inaccurate. Previous releases made progress on this but there's a lot
more to cover.
All RPC methods should be documented first and then the rest of Kiwi's
internals to make development easier!
No vendored JavaScript libraries
There are 11 vendored-in JavaScript files that we carry around in Kiwi TCMS.
Most notable are jQuery plus a few addons and Handlebars.js. To the extent possible
our goal is to use jQuery provided by Django or installed via NPM dependencies!
Less HTML templates with better organization
There are over 100 HTML templates in Kiwi TCMS. There are also email and even
JavaScript templates. For example there are get_cases.html and get_review_cases.html
which are essentially the same. This is kind of also true for templates used in
new and edit views! Such templates should be unified!
Those JavaScript templates need to be totally gone!
All templates are stuffed together in a single directory and their names
are not very predictable. They need to be split per application and follow
some kind of naming convention.
Modern interface with Patternfly
The UI already uses the Patternfly library for some of its widgets. Most notably
the main navigation header. Our goal is for the entire UI to be ported to Patternfly
by updating widgets HTML and CSS where needed.
This will also help clean things up a lot. At the same time we'll be rethinking how
information is organized on screen and how the person interacts with it! Usability
suggestions are very welcome!
This move will also help us get rid of the Handlebars dependency which is now
used for pop-up dialogs.
JavaScript updates and front-end testing
There's lots of JavaScript code on the front-end and honestly we don't quite know
what it does or how it is organized. There are also no tests on the front-end
whatsoever!
It is our goal for this to change with the intention to not overdo the JavaScript
part and keep things very minimal. At the moment we're thinking about vanilla jQuery
that will act as a proxy between the browser and the back-end!
Community efforts
A year ago hardly anybody knew what Kiwi TCMS was, the project didn't even have
this name, there was 1 active contributor and hardly any users! Now the community
has started to slowly revitalize, we're seeing some contributions from our
junior team members (more on this in another blog post) and also seeing
folks installing and using Kiwi TCMS and reporting interesting bugs and feature
requests around it!
For the upcoming year our goal is to seek active engagement with other open source
projects that could make use of Kiwi TCMS and work with them. Kudos to
openSUSE for being the first
to propose such integration!
We're also planning couple of appearances at a few conferences but there's
nothing confirmed yet.
Every other contribution in terms of bug reports, new users and feature requests
is of course welcome but we're very conscious of the fact that there's tons
of work to be done and the team is still very small!
Team wise we'd like to get the existing team members up to speed and tackle
the above tasks with priority. This will also help us introduce bug fixes
and new features more quickly!
Happy testing!