Hi all!

I have worked a bit on some important processes to be more « community-friendly ». Here are the points I wanted to discuss. It is a bit long, but it is important for the future of FreshRSS ! :)

General community process

• A mailing list could be great to communicate between developers and users
• I have to finish the CONTRIBUTING file
• I thought to move all the *.freshrss.org domains on a dedicated VPS to be able to give access to some trusted contributors. It also means it will cost more money to me so it will probably wait until I have a new job ;)
• The new doc (https://github.com/FreshRSS/documentation) has to be installed. daux.io does not support image hosting as I would like so I'll have a look at couscous.io (used by wallabag): we can keep our current doc files, only internal links will have to be updated if we choose to use this doc software.
• Do we need a forum? It seems to me that if we have a mailing list, we don't need a forum.
• What do you think of using Loomio for taking important decisions? Or the mailing list is enough?
• I wanted to create a sort of schema or map to explain to users who want to contribute, where they should begin.
• And a simple question but hard answers I guess: who own the code? I mean, when I was alone to work on FreshRSS, it was easy, I owned the code. But since people can contribute, it's harder to say. Do we need a sort of « collaboration agreement »?

Internationalization process

• We have to update i18n.freshrss.org, at least to explain to not use it!
• CONTRIBUTING file has to explain in few steps how to participate to the i18n
• I think a new string must have, at least, an English version. Other versions (French, German and future supported languages) can use the English version in a first time if contributor don't know the correct translation.
• We'll need later a developer script (e.g. i18n.php) to manipulate translations (e.g. to add a sentence, to rename a key). For now it's ok since we have to take care of only 3 languages.

Quality process

• Use a view template system to have a better MVC architecture separation and facilitate theme contributions
• Considerations about a new, supported and documented PHP framework:
  • Clearly, it's not realistic to entirely rewrite FRSS with a new framework BUT…
  • … we have to improve some controller and model source code by reducing the longest methods and think a bit more to the framework logic (ping @dhoko ;))
  • Comments and code documentation are necessary too
  • I would like to release a new proper version of Minz
• Tests + Travis integration are welcomed (@aledeg has already begun, thanks!)
• Improve documentation
• Reduce size of the README: it's quite a complete documentation page actually
• Improve FreshRSS update process: I always face problems when I release a new version. First step will be to document how to release a version! Next step will be to have a test environment.
• JavaScript code is really too complex to maintain or to understand. We will have to rewrite all of it I think. Has someone some strong knowledges or advices to write nice JavaScript code?
• I really want to improve the contribution process. This point is really important to read for @Alkarex and @aledeg!
  • I would like to avoid direct commits on the dev branch
  • Instead, always open a pull request (PR) so we can review the code
  • A PR must be self-documented and tested. For instance, if you add a new feature, don't forget to document the new code, add a line in the CHANGELOG and add some tests.
  • Before merging a PR, I would like at least two persons read the PR. If it is an new collaborator, @Alkarex, @aledeg or me can merge the PR. If it is one of us, please wait to be reviewed by someone else before merging.
  • The best would be PR are always merged by a person different from the one who opened the PR.
  • These rules should apply for new features or even for bug resolutions (even for a one-line commit)
  • I know it is a lot of constraints (it is for me at least!), but it is to improve code review and so the global quality. It is actually the way Diaspora* team works.
  • Since we are not always available to review code from the others, I can understand if you prefer to keep the old way! But if the community grows up one day, I would like to keep in mind this process.
• I would like to change AGPL3 license by a MIT license. What do you think about that?
• Support Composer (use with extensions too)
• Change official supported PHP version
• Support namespaces

Communication process

• We need a dedicated blog. I think to install a Wordpress: easy, powerful, supported. Or use a static site generator (e.g. Pelican) to generate both website and blog. Bonus: pages and articles could be hosted in a Git repository.
• Articles will be in English, it could be great to have someone to correct them if there are too many mistakes. My English is understandable (I think) but my vocabulary, expressions and grammar are « limited » :-/.
• Update the website
  • Change email contact with the mailing address (please don't use my email address to ask me questions about FreshRSS!)
  • Remove Flattr button
  • Add a link to the blog and Twitter account / tag
• I may give access to the Twitter account to some of us. Tell me if you want but in that case we will have to set up some usage rules.
• I wanted to write an article on LinuxFR to speak about FreshRSS and its « community openness » but not before having mailing list and the CONTRIBUTING file finished.

And… that's all! Thanks for reading :)