Goals
We have many goals for Allura. Here are some objectives and larger "projects" that you can help out with. Learn how to contribute to Allura here and find smaller sized tasks here.
Improve performance
This is a never-ending goal :) We do have many specific tickets related to performance: https://forge-allura.apache.org/p/allura/tickets/search/?q=labels%3Aperformance+AND+status%3Aopen And some research into "hot spots" has been documented at https://forge-allura.apache.org/p/allura/tickets/6388/#263e
Performance measurement can be done with the TimerMiddleware instrumentation that is already wired into Allura. In development.ini set stats.sample_rate as a float between 0-1 and that percent of requests will be instrumented. Timings will be recorded in a stats.log file. Allura also works well with New Relic (a 3rd-party service).
Make Git/Hg/SVN repositories "indexless"
The current repository tools in Allura rely on background jobs to index information into mongo. Over time we have worked on removing that and using direct access to the SCM using the git/hg/svn libraries. Indexing everything in mongo has several limitations:
- it takes time to do before your new commits show up (especially for a whole repo that was imported)
- it increases the size of the mongo database
- it isn't really faster than direct SCM access in most cases
- Allura code has to mimic common SCM functionality, instead of relying on each of the SCM's own implementations (which should be efficient)
See more in our docs at https://forge-allura.apache.org/docs/platform/scm.html?highlight=indexless#indexless Past and current tickets related to the effort are at https://forge-allura.apache.org/p/allura/tickets/search/?q=labels:indexless and particularly [#7828] which is a deep analysis of remaining mongo models.
Documentation
Allura is a very powerful robust system, but lacks documentation explaining how to do everything it can do. Our documentation is published at https://forge-allura.apache.org/docs/ and the source for it is at https://forge-allura.apache.org/p/allura/git/ci/master/tree/Allura/docs/ A few specific documentation needs are ticketed at https://forge-allura.apache.org/p/allura/tickets/search/?q=labels:docs%20AND%20status:open but there are many more need about simply how to do things.
Commenting line-by-line in merge requests
Not much to say, except that it would be a great feature to add! Significant UX and backend work would be required to implement it well. At the moment there is not a ticket for it. Other merge-request related tickets are at https://forge-allura.apache.org/p/allura/tickets/search/?q=labels%3Amerge-requests+AND+status%3Aopen
Dashboard of site stats
It would be great to show site-wide and neighborhood-wide stats in a dashboard. It would include things like # of users registered, # of projects registered, # of developers (users in a project), # of commits, etc. All graphed over time with date range selectors. This would make it easier for sites to know the health of their whole community.
Convert the theme to SCSS (sass)
The theme that comes with Allura is regular CSS files. SourceForge has an internal theme generated from SCSS that is kept in sync with the Allura theme. It has some variations (e.g. header, footer, icons) but is largely the same as the default Allura theme. Since it is quite similar, it could be used as a starting point for a SCSS version of the default Allura theme. Having a SCSS version would make it easier to manage a custom theme, since SCSS/SASS allow for various ways to import and re-use styles.
See http://mail-archives.apache.org/mod_mbox/incubator-allura-dev/201208.mbox/%3C200881DEA7694C0781E1FD7FCE4BCCA1%40geek.net%3E and its replies, for some discussion and support for doing so.
More Importers
Allura's import system is flexible and pluggable. It would be great to have importers developed to handle JIRA tickets, Confluence wiki pages, Bugzilla tickets and GForge projects. GForge and SourceForge's old platform share a common ancestor, so it may be possible for SourceForge to contribute their "project upgrade" script as a starting point for doing direct conversions.
Allura can also export its own tools (but not with attachments, yet....). However it can only import tickets, not any other tools. Each tool should be able to do a full cycle of export and import without any significant losses.
UX improvements
A lot of iterative, individual improvements to Allura's UI/UX would be nice. A number of pages and forms have some rough edges and could be improved. Some tickets for those are at https://sourceforge.net/p/allura/tickets/search?q=labels%3Aux+AND+status%3Aopen but I'm sure there are more possibilities.
Don't use Easy Widgets for JS/CSS minification
As part of [#7919], Broccoli was introduced to do JS builds. (Including ES6 and JSX transpiling). We should expand Brocfile.js to minify & concate all our JS & CSS. And remove EasyWidgets from minifying, concatenating and serving those files. EasyWidgets is non standard and unnecessary, and is a dynamic hit rather than a static file (unless you run a caching server or use a CDN). The one advantage EasyWidges does have is dynamic registering of which JS & CSS to include on any given page. We will probably want to adopt a module system in our JS files, so we know what interdependencies we have. And/or just make one big .js file that has everything and include it on all pages. Browsers will have just one big fetch and then keep it cached.