There is an incipient work regarding federation in Noosfero, which is the seamless interoperability between different social networks. The goal is to make it possible for Noosfero users to interact and share contents with users from any other network that supports a given federation protocol.
There is an implementation proposal fro a basic infrastructure to support federation standards and a proof of concept using the Diaspora protocol. One could propose an alternate implementation with a modern federation strategy, pointing ways to handle remote users and contents, and the approach used to replicate and send data.
Migrate multitenancy support
Multitenancy support in Noosfero is implemented with a custom middleware and database schemas. One could migrate the current implementation to a library that provides a more reliable solution, such as Apartment. That would include rewriting Noosfero init services and configuration, and proposing a different logic to handle multiple domains and environments.
Migrate background jobs library
Noosfero currently uses DelayedJob, which is a deprecated library for background jobs handling. We would like to migrate this strategy to ActiveJobs and a custom backend. This would include rewriting the existing jobs and proposing a migration strategy to handle the existing jobs on production servers.
Refactor file uploading
Currently, Noosfero uses pothoven's attachement_fu to handle file uploads. This is an old and deprecated solution, so we would like to replace it with new technologies (e.g. ActiveStorage).
Additionally, we want to improve the File Upload UI. Some nice features to have would be:
Allow multiple selection of files
Notify end of uploads
Allow selection of name per file
Allow selection of parent folder per file (default to current folder)
One of Noosfero main features is the CMS. The current UI makes the management cumbersome, for instance, there is no way to select a set of contents to perform some batch action. A great contribution would be improvements on the CMS UI, such as introducing a tree based visualization, or enabling group selection and batch operations, like deleting or reordering a set of contents at once.
Even though Noosfero is a Rails multi-page app, the use of some Js framework to build dynamic components would be a great fit for this project.
One of Noosfero features is a chat built over ejabberd. We would like to replace the current implementation with a different solution, such as Converse.js, to reduce the setup overhead and get a more interesting UI. For this project we would also expect automation of the setup and configuration.
The plugins infrastructure is one of the most important features of Noosfero. It allows any developer to change or extend the core behavior, adding new features or adapting the platform to specific domains. Plugins can be installed and activated per network, so each administrator can customize its own environment.
Currently there are some limitations. Plugins must be installed by the system administrator before it is possible to enable them in the environment, and the process may not be completely automated.
One could propose improvements on the current implementation, such as ways categorize plugins with custom metadata (category, labels, status, etc.), a better CLI to manage plugins and install plugins from remote repositories, or even make it possible install plugins in the system using the administration UI in the browser.
Both our user and developer documentations must be updated. A strategy to generate developer documentation from the source code would be a great contribution. We expect the result to be a searchable report of the state of the current API, covering the plugins infrastructure, classes, methods and its respective signatures. This project would also include a strategy to update the developer signature, for instance making use of our CI mechanism.