diff --git a/.github/workflows/extract-i18n.yml b/.github/workflows/extract-i18n.yml index 0098249fb7..035fdf174b 100644 --- a/.github/workflows/extract-i18n.yml +++ b/.github/workflows/extract-i18n.yml @@ -14,6 +14,9 @@ jobs: uses: actions/setup-node@v1 with: node-version: 16 + - name: Install npm v7 + run: | + npm --global install npm@latest-7 - name: Cache Node.js modules uses: actions/cache@v2 with: diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index d574f81854..9a11dd13ce 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -1,46 +1,39 @@ -# Contributor Covenant Code of Conduct +# Simple Code of Conduct -## Our Pledge +## Our Promise -In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. +We commit to creating a welcoming and safe environment for everyone in our community, regardless of personal characteristics or background. -## Our Standards +## Our Rules -Examples of behavior that contributes to creating a positive environment include: +Positive behaviors include: -- Using welcoming and inclusive language -- Being respectful of differing viewpoints and experiences -- Gracefully accepting constructive criticism -- Focusing on what is best for the community -- Showing empathy towards other community members +- Using friendly and inclusive language +- Respecting different viewpoints and experiences +- Accepting feedback positively +- Prioritizing the community's well-being +- Being empathetic to others -Examples of unacceptable behavior by participants include: +Unacceptable behaviors include: -- The use of sexualized language or imagery and unwelcome sexual attention or advances -- Trolling, insulting/derogatory comments, and personal or political attacks -- Public or private harassment -- Publishing others' private information, such as a physical or electronic address, without explicit permission -- Other conduct which could reasonably be considered inappropriate in a professional setting +- Sexual language or imagery, unwanted sexual attention +- Trolling, insulting remarks, personal or political attacks +- Harassment in any form +- Sharing private information without consent +- Any other unprofessional behavior -## Our Responsibilities +## Our Duties -Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. +Project leaders must enforce our rules fairly and take action when they're broken. -Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. +They can remove or edit content, or ban contributors if necessary, to maintain a respectful environment. ## Scope -This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. +This code applies to all project-related spaces and when representing the project or community elsewhere. This includes online and offline interactions and official channels of communication. -## Enforcement -Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at volunteers at trustroots dot org. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. +## Credits -Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. +This code is based on the Contributor Covenant (version 1.4) from [contributor-covenant.org](https://www.contributor-covenant.org/version/1/4/code-of-conduct/). -## Attribution - -This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [www.contributor-covenant.org/version/1/4/code-of-conduct][version] - -[homepage]: https://www.contributor-covenant.org/ -[version]: https://www.contributor-covenant.org/version/1/4/code-of-conduct/ diff --git a/docs/Adding-new-volunteer.md b/docs/Adding-new-volunteer.md deleted file mode 100644 index 7da8e10ff2..0000000000 --- a/docs/Adding-new-volunteer.md +++ /dev/null @@ -1,55 +0,0 @@ -# Adding new volunteers to our systems - -Remember that starting volunteering is hard! Handhold folks as much as possible, and work on making them feel welcome and included. With experienced volunteers, be mindful of [impostor syndrome](https://en.wikipedia.org/wiki/Impostor_syndrome) they might feel. Encouragement and celebration of jobs well done is important. - -## Steps to take when adding new volunteers - -### For everyone - -- Add _volunteer_ role in admin tool. At Trustroots admin tool, find their profile and add "volunteer" role to them. This won't give them any special access, but it makes folks show up at [the team page](https://www.trustroots.org/team) and highlights them as volunteers in their profile. This is important for trust, so that community members can check if they're dealing with someone who truly is with Trustroots. -- Ensure they're invited in [volunteer chat](./Chat.md). -- Ask them [to request account at the wiki](https://wiki.trustroots.org/en/Special:RequestAccount), which you then need to [accept from the list](https://wiki.trustroots.org/w/index.php?title=Special:ConfirmAccounts/authors&wpShowHeld=0). - -### Working on social media - -- Give access to specific social media accounts. Each account should have shared `@trustroots.org` email so that they're not locked behind individuals. Passwords are supposed to be kept in password managers such as [Bitwarden](https://www.bitwarden.com/), never re-use passwords or use passwords that can be memorized. -- Invite to #social-media channel on [chat](Chat.md). - -### Working on newsletter or blog - -- Give them "Editor" level access to blog [by inviting with their email](https://wordpress.com/people/new/ideas.trustroots.org). -- MailPoet access is together with the blog. -- See [newsletter docs](./Newsletter.md) for more. -- Invite to #newsletter channel on [chat](./Chat.md).. - -### Translators - -- Point them at [Weblate](https://hosted.weblate.org/projects/trustroots/) for translations. Ensure their language is listed there, and add them admin access if needed. -- See [translation docs](./Translating-Getting-Started.md) for more. -- Invite to relevant chat room. - -### Support volunteers - -- Ask them to sign NDA because they will have access to private member data, see more below. -- Add _admin_ role in admin tool. This will give them access to Trustroots admin tool. -- Add them to private `#safety` channel on [chat](./Chat.md) -- Add them to ["Safety" team on Github](https://github.com/orgs/Trustroots/teams/safety) — this will give them access to few private repositories with more information. -- Create them a Zendesk account. - -### For developers - -- Add them to ["Devs" team on Github](https://github.com/orgs/Trustroots/teams/devs) — this will give them push access to relevant repositories. -- See [guide for developers](./Development-Getting-Starte.md) for more. - -### For developers dealing with live server - -- Create an account at server and give sudo rights. -- Additionally, if needed, give access to DigitalOcean, Sparkpost, Mapbox, or other systems they need to get the work done. -- Ask them to sign NDA because they will have access to private member data, see more below. - -## NDA - -- There's a template in Google Drive. -- Ask Mikael to send it for signing for each person who has access to private member data. -- Store the signed NDA in Google Drive. -- Mark at admin tool at user's profile the date when they signed NDA. diff --git a/docs/Chat.md b/docs/Chat.md deleted file mode 100644 index be8f61e04a..0000000000 --- a/docs/Chat.md +++ /dev/null @@ -1,11 +0,0 @@ -# Volunteer Chat - -As of November 2022 the [Trustroots volunteers space on Matrix](https://matrix.to/#/#volunteers:trustrooters.org) is more active than the [Slack](https://trustroots.slack.com/) we were using previously. - -There are many Matrix clients, but [Element's web app](https://app.element.io/) is currently a good first choice for most people. Element is also available for many other platforms. You can create a Matrix user account thru Element relatively easily. - -TU Dresden has good documentation about using Matrix, including the [first steps](https://doc.matrix.tu-dresden.de/en/first-steps/). - -It would be great if you could use your Trustroots username as your Matrix username and/or name so that people can easily recognise you. - -If you have questions, contact [the support team](https://www.trustroots.org/support). diff --git a/docs/Design-Getting-Started.md b/docs/Design-Getting-Started.md deleted file mode 100644 index 43194985e1..0000000000 --- a/docs/Design-Getting-Started.md +++ /dev/null @@ -1,28 +0,0 @@ -# Getting started with design - -## Where work happens - -Suppose you've already dropped by at [volunteer chat](Chat.md) at this point and if you haven't, you should! Lots of the design discussions happen there. - -Repositories — see "issues" and "pulls": - -- [Website](https://github.com/trustroots/trustroots) -- [Mobile](https://github.com/trustroots/trustroots-expo-mobile) - -## Getting started - -Getting started with development or other tasks at Trustroots is fairly straightforward compared to design. - -We don't currently have design/development process. While we do have distinctive features at the site, they all fit together to form a more cohesive experience and thus understanding the big picture might feel challenging. Making changes requires a bit deeper understanding of how everything interacts, what are the goals of different flows etc. Generally, not having too many assumptions and just asking lots of questions should make it easier. - -That said, there's lots to do! - -If you're more UX/UI type person, we can figure out out specific tasks around features that need designing. - -If you're more product designer type, starting carving out the said design process and thinking how our flows could be improved is a great place to start. - -As a project we have a history of designer volunteers dropping out fairly early on, which is something we'd like to change and need _your_ help with. While there is always something to do on development side, doing design might require quite a bit of patience from you since things aren't always moving as fast as you'd like them to. - -## Further studying - -Familiarise yourself little bit more with rest of the [documentation and guides](https://team.trustroots.org). diff --git a/docs/Development-Getting-Started.md b/docs/Development-Getting-Started.md deleted file mode 100644 index 23fa5cf4b3..0000000000 --- a/docs/Development-Getting-Started.md +++ /dev/null @@ -1,97 +0,0 @@ -# Getting started with Development - -## Where work happens - -Technical conversations often happen either on our GitHub repository -or the [volunteer chat](Chat.md). - -Source code: - -- [Website source code](https://github.com/trustroots/trustroots) -- [Mobile app source code](https://github.com/trustroots/trustroots-expo-mobile) (a simple, webview based app) -- [Mobile app source code](https://github.com/Trustroots/trustroots-mobile) (our future, fully native app with React Native) - -## Stack - -Trustroots is fully written in JavaScript (both back- and frontend) on [Node.js](https://nodejs.org). - -Our main data storage is [MongoDB](http://www.mongodb.org) which is a Document Database (and not a relational database like SQL databases are), and we access it with [Mongoose](https://mongoosejs.com/) which gives us Object Models. - -We store additional data in [InfluxDB](https://www.influxdata.com/) for statistical purposes but developers typically don't need to interact with InfluxDB. - -Our backend framework is [Express.js](https://expressjs.com/). - -Our frontend framework is [React](https://reactjs.org/). - -The application is compiled and served using [Gulp](https://gulpjs.org/) and [Webpack](https://webpack.js.org/). - -[Babel](https://babeljs.io/) that transpiles modern ES6 frontend code back to ES5 that most browsers understand. - -Our stylesheets are written in [LESS](http://lesscss.org/) language and our UI uses [Bootstrap v3](https://getbootstrap.com/docs/3.3/) (not the latest v4) framework quite extensively. - -## Architecture in short - -- Express.js server side serves content from API end-points. -- In backend code, you would typically interact with [Mongoose](https://mongoosejs.com/) object models such as "Tribe" or "User". These match MongoDB collections "tribes" and "users". -- React.js single page application reads data from the API and renders templates. -- The application is divided into modules by main features; one for messaging, one for users etc. Each module contains server-side files, client-side files and tests for that specific feature: - -``` -└── modules - └── module-name - ├── client - ├── server - └── tests - ├── client - └── server -``` - -[Development documentation](Development.md) dives deeper into architecture and folder layout. - -### Codebase' origin - -Trustroots was built upon [MEAN.js boilerplate](http://meanjs.org/) (from _Mongo-Express-Angular-NodeJS_). MEAN [isn't active anymore](https://github.com/Trustroots/trustroots/issues/638) and we've modified the codebase extensively for our own purposes, so it's better not to rely too much on [their documentation](http://meanjs.org/docs.html). - -While boilerplate was a great way to get started with rather large application, we inherited a lot of cruft and kinda complicated setup from it. As time has passed, several aspects of the application are not that modern anymore and we have [lots to do](https://github.com/Trustroots/trustroots/projects/4) to bring it up to date. - -Note that [meanjs.org](http://meanjs.org/) and [mean.io](http://mean.io/) are two separate projects. The former [was a fork of mean.io in 2014](http://blog.meanjs.org/post/76726660228/forking-out-of-an-open-source-conflict). Trustroots was built on the meanjs.org version. - -## Where to start? - -Suppose you've already dropped by at [volunteer chat](Chat.md) at this point and if you haven't, you should! - -Then the first step is to [get the application running](Install.md) and perhaps familiarise yourself little bit more with rest of the [documentation](https://team.trustroots.org). - -[Easy issues](https://github.com/Trustroots/trustroots/issues?q=is%3Aissue+is%3Aopen+label%3Aeasy) are a great place to start work. These should be issues which are fairly easily fixable. - -Hopefully with a little diving into the code, you should be able to find and fix one or two of these issues. If you're just starting out with the code, these are a great way to contribute something really useful very quickly. - -Adding more significant features, major refactoring, and so on are typically handled by more experienced developers in the team. - -Make sure to familiarise yourself with our [pull request workflow](Pull-Request-Workflow.md). - -## How to write code - -- Tests, tests, tests! It's important to have unit tests cover especially for backend APIs because we are many people writing code and changing code in one place might break it at another. Lots of our client side code lacks tests and while these aren't always necessarily as useful as backend tests, writing some tests would be great, too. Add tests especially if you've fixed a bug in APIs. -- Write [JSDoc](http://usejsdoc.org/) comment blocks, please, or add them when you see them missing. -- Check your code for [Accessibility](Accessibility.md). - -## Coding conventions - -- Project has [`.editorconfig`](https://github.com/Trustroots/trustroots/blob/master/.editorconfig) file — [download extension for your editor](http://editorconfig.org/#download). -- Configure Eslint integration for your editor - -## Deeper Dive - -Check out the [Development docs](./Development.md) for more info about tooling, mock data, running tests, etc. - -## Further studying - -Official [React documentation](https://reactjs.org/) is great. - -While our JavaScript codebase is mostly still in older ES5 format, we are fast moving towards modern ES6. Here are few resources to get up to speed with ES6: - -- [JavaScript Allongé, the "Six" Edition](https://leanpub.com/javascriptallongesix/read) -- [Exploring ES6](http://exploringjs.com/es6/) -- [What the heck is the event loop anyway?](https://www.youtube.com/watch?v=8aGhZQkoFbQ) – short presentation that sheds some light on how asynchronous operations are executed in JavaScript -- [ES6 cheatsheet](https://github.com/DrkSephy/es6-cheatsheet) diff --git a/docs/Development.md b/docs/Development.md deleted file mode 100644 index 0ee8dc2467..0000000000 --- a/docs/Development.md +++ /dev/null @@ -1,327 +0,0 @@ -# Development, in-depth documentation - -For a high-level overview, see the [getting started docs](./Development-Getting-Started.md). - -# The application - -- **MEAN** stack, seeded originally with [MEAN.js](http://meanjs.org/) boilerplate: [MongoDB](www.mongodb.org), [ExpressJS](http://expressjs.com/), [AngularJS](https://angularjs.org/) v1 ([we're migrating](./React.md) to [React](https://reactjs.org/)), [NodeJS](http://nodejs.org/). Additionally stuff like [Bootstrap](http://getbootstrap.com/) v3 for component styles, [Leaflet](http://leafletjs.com/) for the map, etc. -- Database scheme (look for `*.server.model.js` project files to check most up to date info) -- We're migrating the client to React. Read a [migration guide](React.md). - -# The mobile app - -- We have [a basic Webview app](https://github.com/Trustroots/trustroots-expo-mobile/) written in React Native and Expo.io which mostly just gets you push notifications and an icon on phone's screen. :-) -- We have [in-the-works React Native app](https://github.com/Trustroots/trustroots-mobile/). - -## Coding conventions - -- Project has [.editorconfig](https://github.com/Trustroots/trustroots/blob/master/.editorconfig) file, we recommend to [download extension for your IDE](http://editorconfig.org/#download). -- Build script checks all the files against our [ESLint rules](https://github.com/Trustroots/trustroots/blob/master/.eslintrc.js). Fix errors before submitting PR and add integration for your IDE. -- [Prettier](https://prettier.io/) codeformatter is configured so you might want to install integration for your IDE. - -### Other conventions - -- File names use dash to separate words. For example: foo-bar.js (except for React Components `CamelCase.js`) -- Use camelCase for identifiers. Functions and variable names should be named like `doAThing`, not `do_a_thing`. - -### JS - -- See [Angular 1 Style Guide](https://github.com/johnpapa/angular-styleguide/blob/master/a1/README.md) -- We're migrating to ES2018. Write your code in modern JavaScript. Read a [migration manual](ES2018.md). - -### CSS/LESS - -- We use [LESS CSS](http://lesscss.org/) for CSS. -- Build as generic and re-usable components as possible. Rather `.panel` than `.about-box`. - -#### CSS class names - -- Name reusable bits of layouts by module names and keep them out of page styles, (eg. `.group-badge` can be used in multiple places around the site.) -- Related elements within a module use the base name as a prefix. For example module `.panel` has also `.panel-header`, `.panel-body` and `.panel-footer`. -- Prefix state rules with `.is-` (for example `.is-collapsed`). - -## Route conventions - -_**TODO: Outdated**_ - -Convention is as follows: - -- Url has the plural like `/messages/`, `/users/`, `/users/:userId/photos`, `/users/:userId/references` -- The id is the singular name followed by `Id` like `userId`, `photoId`, etc -- The route with the id is called nameSingle like `usersSingle`, `offersSingle`, etc -- Template name matches route name -- Nested routes are simply concatenated like `usersSingleReferences` or `usersSinglePhotosSingle` - -### Examples - -- `/users` route name `users` -- `/users/:username` route name `usersSingle` -- `/users/:username/edit` route name `usersSingleEdit` -- `/users/:username/photos` route name `usersSinglePhotos` -- `/users/:username/photos/edit` route name `usersSinglePhotosEdit` -- `/users/:username/photos/:photoId` route name `usersSinglePhotosSingle` -- `/users/:username/photos/:photoId/edit` route name `usersSinglePhotosSingleEdit` -- `/messages` route name `messages` -- `/messages/:userId` route name `messagesThread` - deviates because it is `userId` not `messageId` - -## Testing - -#### Strategy: - -##### CI setup - -Slowly getting there. Any help/experiences appreciated! [#228](https://github.com/Trustroots/trustroots/issues/228) - -##### Unit tests - -...mainly to test Mongo models ([example](https://github.com/Trustroots/trustroots/blob/master/modules/users/tests/server/user.server.model.tests.js)). - -...as well some critical bits of Angular frontend ([example](https://github.com/Trustroots/trustroots/blob/master/modules/users/tests/client/authentication.client.controller.tests.js)). - -##### Integration tests - -... mainly for the API routes ([example](https://github.com/Trustroots/trustroots/blob/master/modules/messages/tests/server/message.server.routes.tests.js)). - -##### Clientside Component tests - -- Look for `modules/*/tests/client/components` -- Written with [React Testing Library](https://www.npmjs.com/package/@testing-library/react) - -#### Run tests - -- `npm test` for everything, -- `npm run test:server` for Mocha tests, -- `npm run test:server:watch` same with watching, -- `npm run test:client` for testing Karma-unit tests and -- `npm run test:selenium` to run old outdated Selenium tests. Requires Python. Make sure Trustroots is running already as this task won't spin it up first. This task isn't included in the main test task. If you want to pass custom domain to test for Selenium you can do so by running: `python ./scripts/selenium/test.py https://dev2.trustroots.org/` - -## Development tools - -### Emails - -MailDev is there for viewing and testing emails during development. - -[MailDev](https://github.com/maildev/maildev) will be already running at [localhost:1080](http://localhost:1080) but if you need to run it manually, type: - -```bash -npm run dashboard:mail -``` - -### Background jobs - -[Agendash](https://github.com/agenda/agendash) is a dashboard & inspector for [Agenda](https://github.com/agenda/agenda), our job scheduling library. - -To run it at [localhost:1081](http://localhost:1081), type: - -```bash -npm run dashboard:jobs -``` - -## Debugging - -The standard node inspector runs on each start for the main app (port 5858) and the worker (port 5859). - -To debug using Chrome: - -1. Run 'npm start' -2. Open `chrome://inspect/#devices`. Note the "Remote Target" list should be empty to start -3. Press "Open dedicated DevTools for Node" -4. Press "Add connection" and add both `localhost:5858` and `localhost:5859` -5. They will now appear in "Remote Target" list -6. Press 'inspect' on whichever process you want to debug -7. You should now have console/profiler etc available. - -More information can be found in the NodeJS [debug documentation](https://nodejs.org/en/docs/guides/debugging-getting-started/). - -## Access the server from another device - -- Make sure you are connected to the same network (WIFI/LAN). Find your ip address using `ipconfig` or `ifconfig`. -- Add `host: null` into `config/env/local.js` -- Alternatively you can also use service like [Ngrok](https://ngrok.com). - -## Analyzing bundles - -You can see what goes into the "bundle" that [Webpack](https://webpack.js.org/) compiles from all the JS, style and image assets by adding this to your `config/env/local/js`: - -```js -bundleAnalyzer: { - enabled: true, - // See https://github.com/webpack-contrib/webpack-bundle-analyzer#options-for-plugin - options: {}, -}, -``` - -Now when you start the application, [bundle analyzer](https://github.com/webpack-contrib/webpack-bundle-analyzer#readme) will automatically open new browser tab at `http://127.0.0.1:8888/` that shows you information about the bundle. - -## Coding styles - -We apply [Eslint](https://eslint.org/) rules to our JavaScript files and automatically format them using [Prettier](https://prettier.io/). You should install [Eslint editor integration](https://eslint.org/docs/user-guide/integrations#editors) as well [Prettier editor integration](https://prettier.io/docs/en/editors.html) to notice code formatting errors and let the editor autoformat files for you automatically. - -Files are autoformatted by Prettier each time you `git commit` your changes. - -Files are also continuously linted as you modify them when running `npm start`, but if you need to lint all the files separately, run: - -```bash -npm run lint -``` - -To continuously lint files as you modify them, run: - -```bash -npm run lint:watch -``` - -To let Eslint fix linting errors automatically, append `-- --fix` to either regular lint or -watch command like so: - -```bash -npm run lint:watch -- --fix -``` - -## Mock data - -There is a data script that the individual mock data scripts with default values to generate mock user data, hosting offers, messages and tribes. It's highly recommended you run this script after installation, that way you'll have something to look at. - -Run `npm run seed` - This will add automatically add: - -- 100 tribes -- 1000 users including 3 users with user names of `admin1`, `admin2`, `admin3` each with the password of `password123` -- 2000 message threads with 1 to 10 messages in each thread - -For more custom setups, you can alternatively run the scripts for generating data individually. It is currently recommended that you run them in the sequence provided below. - -1. To add tribes, run `npm run seed:tribes 50` — This will create 50 tribes. - - - Run this prior to adding users to add users to tribes automatically - -2. To add users, run `npm run seed:users 1000 -- --userNames adminusername` — This will create 1000 users and hosting offers. `adminusername` is optional (a-z0-9) and will create an admin user. - - - It can take up to 5 minutes. Mongoose might complain about duplicates — just ignore these errors. - - To see the result, log in with your chosen username and password `password123`. - - Additional admin usernames are also supported (eg. `npm run seed:users 1000 -- --userNames admin1 admin2 admin3`) - - If tribes exist, users will also be added to random tribes - -3. To add messages, run `npm run seed:messages 1000 10` — This will create 1000 message threads between random users with up to 10 messages in each thread. - -All scripts additionally support `--debug` and `--limit` flags showing database debug information and not creating new elements if the number of database items already exist respectively. - -## Clean database - -To drop your database, run: - -```bash -npm run dropdb -``` - -## Enable FCM push notifications (optional) - -1. Create [FCM account](https://firebase.google.com/) - -2. Go to [FCM console](https://console.firebase.google.com/) and create a new project - -3. Open the project and hit the small gear next to "Overview" at the sidebar so that you get to "project settings" page - -4. Choose "Cloud messaging" tab, copy "Sender ID" number - -5. Choose "Service accounts" tab - -6. Either "create new service account" via "Manage all service accounts" link or choose existing one from the list (for development, "Firebase Admin SDK" account is fine) - -7. Click on the "Generate new private key" button - -8. Choose "json" format and you'll get a file to download - -9. Add contents from that file to your `./config/env/local.js`: - - ```js - fcm: { - senderId: 'PASTE_YOUR_SENDER_ID_NUMBER_HERE', - serviceAccount: PASTE_YOUR_JSON_CONFIG_HERE - }, - ``` - -10. To stop Eslint from complaining, you might need to convert double quotes to single quotes. (`"` → `'`) or [disable Eslint](https://eslint.org/docs/user-guide/configuring#disabling-rules-with-inline-comments) for those lines. - -## Enable collecting statistics to InfluxDB (optional) - -1. [Install InfluxDB](https://docs.influxdata.com/influxdb/) v1.0+ and run it (type `influxd`) - -2. Add InfluxDB configuration to your `./config/env/local.js`: - - ```js - influxdb: { - enabled: true, - options: { - host: 'localhost', - port: 8086, // default 8086 - protocol: 'http', // default 'http' - // username: '', - // password: '', - database: 'trustroots' - } - } - ``` - -3. You can observe data through InfluxDB admin panel: [localhost:8083](http://localhost:8083/) or optionally [install Grafana](http://docs.grafana.org/installation/) and connect it to InfluxDB. - -4. [Read more](INFLUXDB.md) about the collected data and metrics - -## Use ImageMagick instead of GraphicsMagick - -If you prefer [ImageMagick](http://www.imagemagick.org/) over [GraphicsMagick](http://www.graphicsmagick.org/): - -1. In MacOS, you can simply use [Homebrew](https://brew.sh/) to install it: - - ```bash - brew install imagemagick - ``` - -2. Change `imageProcessor` setting from `./configs/env/local.js` to `imagemagic`. - -## Folder layout - -You might want to read the [folder structure](http://meanjs.org/docs.html#folder-structure) to get a handle on how things are laid out, although we've started deviating from it with Angular.js to [React migration](./React.md). A quick summary: - -- `modules/` contains one folder for each "component" of the site, this is where most of the interesting stuff lives -- `modules/**/server/` contains all the backend, server side stuff - - `/models` defines the [Mongoose](https://mongoosejs.com/) models. There are only a few, so it might be worth scanning them to understand the data model. For in depth description, see [[database]]. - - `/controllers` as you'd expect, Express controllers live here. - - `/routes` links url paths to controllers - - `/tests` defines tests run server side - - `/jobs` [Agenda](https://www.npmjs.com/package/agenda) job scheduler (~cron) jobs (see config/lib/agenda.js for more) - - `modules/core/server/views` contains email templates and initial rendered index.html -- `modules/**/client/` contains all the client side stuff - - `modules/core/client/app` - - `modules/core/client/app/less` contains the site wide style variables and `application.less` file which includes rest of the modules. - - `/less` is where you'll find **CSS styles** in [LESS format](http://lesscss.org/). Each module should have .less file with the module name, which then includes rest of the less files from the same folder. E.g.: `modules/core/client/app/less/application.less` includes `modules/messages/client/app/less/messages.less` which then includes `inbox.less` and `thread.less` from the same directory. - - `/views` is where you'll find Angular.js templates - - `/api` functions for communicating with REST API points, used in React components and not with Angular.js stuff; Angular uses `/services` insteead. - - `/services` is where you'll find [Angular service](https://docs.angularjs.org/guide/services), mostly for connecting to REST API points. Not used in React components; those use `/api` instead. - - `/config` contains the client side routes and other configs - - `/directives` contains the [Angular directives](https://docs.angularjs.org/guide/directive) - - `/controllers` contains the angular client side [controllers](https://docs.angularjs.org/guide/controller) - - `/components` contains React components. [Read more about our React migration](./React.md) - - `/utils` containts utility functions used mostly with React components. - - `/images` Images for the module. -- `config/` ta-da, configs! Server side. - - `/assets` Defines paths for assets (serverside JS, frontend CSS/JS/LESS, lib files etc) - - `/lib/env` primary config files. Don't modify anything else here except `local.js`. - - `/lib/env/local.js` file overriding other `env/*` files. Put here your adjustments you don't want have publicly at the repo (it's git-ignored). - - `/lib/agenda.js` [Agenda](https://www.npmjs.com/package/agenda) job scheduler (kinda like cron) - - `/lib/worker.js` Configures all cron jobs with above Agenda - - `/lib/express.js` Sets up the server side application and routes - - `/lib/app.js` Boot up function for the serverside app. - - `/lib/facebook-api.js` Sets up Facebook Graph API client - - `/lib/firebase-messaging.js` Sets up Firebase for push notifications - - `/lib/mongoose.js` Sets up database connection and related utilities. - - `/lib/render.js` Configuration for Nunjucs, a serverside template renderer - - `/lib/logger.js` Configures error logging service - - `/lib/exponent-notifications.js` Expo.io based mobile app push notifications -- `server.js` server entrypoint; for APIs and serving the fontend client -- `worker.js` background job runner entrypoint, for running Agenda -- `package.js` dependencies, managed with [NPM](https://www.npmjs.com/) - -## Support - -- Check and open issues at [GitHub](https://github.com/Trustroots/trustroots/issues) -- [Contact us](https://www.trustroots.org/contact) -- [Volunteer chat](https://team.trustroots.org/Chat.html) diff --git a/docs/ES2018.md b/docs/ES2018.md deleted file mode 100644 index 1385b555b1..0000000000 --- a/docs/ES2018.md +++ /dev/null @@ -1,101 +0,0 @@ -# A guide for ES2018 migration - -Write code in modern JavaScript! - -This manual is meant for server-side code, but is largely valid for the whole application. - -## Tell eslint - -Let's assume you (re)write a file 'modules/users/server/somefile.js' in ES2018. - -Open [.eslintrc.js](../.eslintrc.js). Find a section `overrides`. Add your file to `files` in `overrides for server code`. - -```js -// ... -overrides: [{ - // ...other overrides -}, { - // overrides for server code - // ES2018 - specify migrated files and folders here - files: [ - ... - 'modules/users/server/somefile.js', // add the path to your file here - ... - ] -}] -``` - -_Note: You can add whole folders. See the [.eslintrc.js](../.eslintrc.js) for examples._ - -## Promises and async/await - -Replace [async](https://caolan.github.io/async/) library and [callback hell](http://callbackhell.com/) with [Promises](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) and [async/await](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function). - -Try to find out whether your library of choice offers promise versions of library methods. Study the documentation how to use them. For example many methods in [mongoose library](https://mongoosejs.com/docs/guide.html) support Promises. - -If only a callback method is available, wrap it with [`util.promisify()`](https://nodejs.org/api/util.html#util_util_promisify_original), or use a different library. - -Explaining Promises and async/await is beyond the scope of this document. There are some excellent articles out there for this purpose. Ask your fellow developers if you get stuck or don't understand something. - -(TODO add some links to those excellent articles) - -[See an example - rewrite async.waterfall to async/await](./Async-waterfall-to-async-await.md) - -## Destructuring - -Use [destructuring](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment) to avoid repetition. - -### Destructuring objects - -```js -// before -var foo = { - bar: bar, -}; - -// now -const foo = { - bar, -}; - -// before -var foo = bar.foo; - -// after -const { foo } = bar; -``` - -### Destructuring arrays - -```js -// before -var x = [0, 1]; -var a = x[0]; -var b = x[1]; - -// after -let x = [0, 1]; -let [a, b] = x; -``` - -## Import - -To load modules in Node.js use `require` as before. In React you can use `import`. - -## var => let, const - -Don't use [`var`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/var). If you're going to change a variable, declare it with [`let`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let). Use [`const`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const) everywhere else. - -_Note:_ `var` have function scope, but `let` and `const` have block scope. - -## Spread syntax (...) - -[Spread syntax](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax) and [Rest parameters](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/rest_parameters) can make your life easier. - -## Arrow functions () => () - -Use [arrow functions](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions). - -## Tests - -Mocha likes Promises. They simplify things a lot. diff --git a/docs/Monitoring.md b/docs/Monitoring.md deleted file mode 100644 index 02d2b19a17..0000000000 --- a/docs/Monitoring.md +++ /dev/null @@ -1,24 +0,0 @@ -# Monitoring - -## Application monitoring - -See docs how to check [Passenger's status](https://www.phusionpassenger.com/library/admin/nginx/overall_status_report.html). - -## Server monitoring - -### DigitalOcean - -See DigitalOcean dashboard for details. - -### PaperTrail - -- For syslog and Nginx error log. -- [PaperTrailapp.com](https://papertrailapp.com/dashboard) - -## Uptime - -- [UpDown.io](https://updown.io/) is monitoring various Trustroots sites - - Public status page at [status.trustroots.org](http://status.trustroots.org/) - - Alerts via emails, SMS and [Chat](Chat.md) at #tech channel. -- WordPress Jetpack is monitoring `ideas.trustroots.org` - - Alerts via emails diff --git a/docs/Newsletter.md b/docs/Newsletter.md deleted file mode 100644 index 6f1626e81e..0000000000 --- a/docs/Newsletter.md +++ /dev/null @@ -1,48 +0,0 @@ -# Newsletter - -Occasionally we send a newsletter to our members. - -## Sending newsletter - -### Creating campaign - -Create campaign on MailPoet. It's the plugin we use for sending newsletters. - -It's accessible with same account and URL as our blog: - -- [Login](https://ideas.trustroots.org/wp-admin/) -- [MailPoet admin](https://ideas.trustroots.org/wp-admin/admin.php?page=mailpoet-newsletters) - -If you don't have an account yet, create one at [wordpress.com/start/account](https://wordpress.com/start/account) and ask someone to add you to the site. - -### Updating subscribers - -MailPoet's subscribers and subscribers on the actual site's database are not synchronised automatically. Therefore you need to manually update the list each time you want to send out a campaign. - -Go to Trustroots admin panel to [export list of newsletter subscribers](https://www.trustroots.org/admin/newsletter) as a CSV file. - -Go to importing tool in MailPoet ([_MailPoet → Subscribers → Import_](https://ideas.trustroots.org/wp-admin/admin.php?page=mailpoet-import)) and create a new import with the file. It doesn't matter if the CSV file has some existing emails — MailPoet's import will ignore those. - -Remember to delete both files after you don't need them anymore. Especially the local one. - -### "From" email - -You have a couple options for "from" email. You can override defaults for each campaign in MailPoet separately. - -If you use our `support@` address, people's replies go to our support tool, for the support team to read. - -If you would prefer other folks in your team to read replies, use `share@` email as sender. There's a list of emails at [Zoho's email admin](https://mailadmin.zoho.com/) panel to whom this email gets forwarded. - -Note that we typically get a dozen or so "out of office" auto-replies, so it shouldn't get too noisy. You can also create filters for yourself to funnel all newsletter related emails to a separate folder. - -If you don't want replies to newsletter, use `no-reply@` address. - -### Rollout - -Test the campaign first by sending it to a small, internal test list. Once that works out, do the full-rollout on the main list. - -Sending emails is throttled across long enough time. That's so that email providers like Gmail don't flag us for spam when they see a sudden surge of mass email coming out from our servers. Therefore it can take little while before the whole list is processed. Our throttle is currently (2020/12) 100 emails per 5 minutes (that's 28,800 emails per day). This can be adjusted from _Settings → Send With… → Configure_. [Read more about sender reputation](https://www.sparkpost.com/resources/email-explained/email-sender-reputation/). - -### Social media - -Consider also creating a blog and social media material from the newsletter. diff --git a/docs/Pull-Request-Workflow.md b/docs/Pull-Request-Workflow.md deleted file mode 100644 index f1e7cc7306..0000000000 --- a/docs/Pull-Request-Workflow.md +++ /dev/null @@ -1,20 +0,0 @@ -## Pull request workflow - -- `master` is the most up-to-date, development branch. -- Start new branches directly at Trustroots repository and use descriptive names so that it's easy to keep track of them. E.g. `fix/profile-description` or `add/references-api`. - - If you're not actively working on Trustroots yet, just fork the project and send pull requests from your repo. We will give you commit rights early on. -- When you have some code ready, feel free to open a Pull request (PR). At this point you don't have to be "done"; it's okay to open PR as early as possible and thus get early feedback. -- Ideally PRs are as small and focused as possible. That ensures that they are easy to review and quick to merge. If feature isn't ready yet, we can hide it behind a feature flag and keep it visible only for developers. You could for example PR a skeleton of a new API in one PR and work on the API in follow up PRs. Bigger the PR, slower and harder it is to review. -- Preferably PRs are _reviewed_ and _tested_ by someone. Because of lack of volunteer time, there are some more experienced folks with deeper understanding of the whole codebase, who might merge their PRs directly without reviews. This isn't ideal but acceptable in current volunteer situation. - - Most experienced people with the codebase are @simison and @mrkvon (as of 2/2019). -- To make reviewing easier, write clearly what is the reasoning for the change and if possible, also testing instructions. -- Each commit in PR launches automated tests in Travis CI and results are reported in the PR. Make sure to keep tests from failing. -- Once PR is accepted, you can hit "Squash & merge" on GitHub yourself. Squashing is important so that the commit log stays easier to read and so that it's easier to revert changes if they cause regressions. -- Every now and then @simison merges `master` branch to `production` branch and deploys that branch to production server. - -Folders where PR workflow can be relaxed, since application code isn't touched: - -- bin/admin -- deploy -- docs -- scripts diff --git a/docs/Services-and-resources.md b/docs/Services-and-resources.md deleted file mode 100644 index 0229de728b..0000000000 --- a/docs/Services-and-resources.md +++ /dev/null @@ -1,39 +0,0 @@ -# Services and Resources - -Store possible _future_ services, examples, resources (e.g. blog -posts) etc that don't fit under any specific todo. - -## SMS gateways - -- https://www.nexmo.com/ (used at [Hitchticker](https://github.com/guaka/hitchticker/issues/2)) -- https://www.twilio.com/ - -## Offline docs - -- http://devdocs.io/ (free, browser based) -- https://kapeli.com/dash (paid, OSX) - -# Donations / finances - -## Payment systems - -- https://stripe.com/ (no non-profit pricing, used by Warmshowers) -- https://www.braintreepayments.com/ -- http://www.paypalobjects.com/webstatic/mktg/Nonprofit/NonProfitFAQ.pdf - -- https://cash.me/ - -## Bitcoins - -- http://bitcoin.stackexchange.com/questions/36899/whats-a-good-way-to-receive-donations - -## F/OSS Administration/funds - -- [Snowdrift](https://snowdrift.coop/) - patronage system funding freely-licensed works -- [NLnet Foundation](https://nlnet.nl) -- [BountySource](https://www.bountysource.com/teams/trustroots) -- [GratiPay](https://gratipay.com/for/trustroots/) - -# Interesting data sources - -- https://www.google.com/maps/d/u/0/viewer?mid=zCUrDZ_sv7Fw.k9HCrqv3hIVA&hl=fr&usp=sharing (in French and a lot in France) diff --git a/docs/Translating-Getting-Started.md b/docs/Translating-Getting-Started.md deleted file mode 100644 index 853a83da0e..0000000000 --- a/docs/Translating-Getting-Started.md +++ /dev/null @@ -1,65 +0,0 @@ -# Getting started with Translating - -This is a brief introduction to working with translating/reviewing for -Trustroots. If you have questions that are not answered below, you are -welcome to contact the localisation team, which at the moment is -easiest to do through [chat](Chat.md). - -## Using Weblate - -We are currently using Weblate for localisation, you can find basic information on how to work with the tool below: - -- You can find the Trustroots localisation files at: https://hosted.weblate.org/projects/trustroots/ -- In order to save segments instead of just suggesting translations you need to register (accounts on GitHub etc. also accepted). -- In your Weblate Settings you can, apart from your working language(s), add any secondary languages that you understand. This will show available translations in addition to the source string, which can help out with context. -- Clicking on "Languages" on the /trustroots page lets you choose the language you want to work on (with "Browse"). -- On the language page you will see a list of available files as well as information on how much has been translated in each file and so on. From here you can either open individual files and start from the first segment, or you can click on the number of comments to show only commented segments etc. -- If you want to add a new language (opening a Component and clicking "Start new translation") but have problems doing so, get in touch with the localisation team and we will try to sort it out. - -## Translations - -If you are the first person to work on a language, or if there are still untranslated segments, the pointers below might be of use: - -- For context it can be helpful to have Trustroots open either in another window (side by side) or in another tab that you can switch to easily (see your browser specifications for shortcuts). -- If you feel sure about your translation, use the button "Save", otherwise you can use "Suggest" to mark it up for review. -- Do not translate placeholders! (but remember to include them in your translation): - - Words in {{double curly brackets}} should stay as they are. - - Tags such as <1>, <2>, , etc. should be left, but the words in between should be translated (these tags will be replaced by html tags later). -- If you want to you can create a glossary for terms that are used frequently. You can also have a look at the glossaries for other languages for ideas of what to include. - - You can add words/terms either by clicking "Add word to glossary" in the editor or going straight to the glossary under /trustroots. - - When a word has been added to the glossary it will show as a suggestion when occurring in part of a string. -- Context issues: - - If context is unclear and you cannot find the segment in Trustroots, you can also check "Other languages" to see how others have translated the segment. - - If your uncertainty is language-related (e.g. whether Term A sounds better then Term B in your language), add a comment to the segment so that the reviewer can consider the options and discuss them with you. - - If you have grave doubts it is better to "Suggest" than "Save" the translation. - - If it is a general question that could apply to other/all languages instead, please check if it has already been mentioned among the Translation Queries. If not, feel free to add it there and notify the rest of the localisation team to get feedback on your query. -- If you look at segments marked up as "Checks" you can find simple errors such as differing end punctuation, incorrect tags etc. -- See the last reviewer note below, it applies to you too :) - -## Review - -If the translation has been completed, the next step is a review by another person, which would generally go something like this: - -- Read through all the files and make sure the language sounds natural, that there are no typos, grammatical errors etc., and pay attention to potential comments. - - If answering a comment, use "@" to notify the other person of your answer. -- If something is not technically incorrect, but sounds strange to you, discuss it with the translator to find the best solution. -- Make sure that there are no errors such as untranslatable tags that have been translated etc. -- Go through segments marked up as "Checks" to make sure that the only ones remaining are false positives suitable for your language. -- Remember that although people can have strong opinions on language, you are working with the translator, not against them. Good communication tends to make this less of an issue. - -## Conflict Resolution - -Occasionally there might be disagreements on how to translate certain terms or what register to use etc. In these situations you should try to explain your point of view while listening to that of others - aiming to finding common ground to make a decision from. If it, for some reason, is not possible to come to an agreement we would recommend getting in touch with the others in the localisation team (through chat or any other communications channel) in order to get more neutral opinions on the matter and, if needed, a moderated video conversation or a similar solution to find a way to resolve the conflict. - -## Deploying changes - -- After you make changes on Weblate, they appear at [GitHub as a pull request](https://github.com/Trustroots/trustroots/pulls?q=is%3Apr+author%3Aweblate+). Changes get piled into one pull request until that gets "merged". You can subscribe to the pull request in Github to get notified when the pull request gets merged. -- After merging, changes will appear on the developer's local setups as well on [the dev2](https://dev2.trustroots.org/) environment. -- Changes need manual deployment to appear on the production site, which we do every now and then, usually within a week or two. Feel free to ask for a new deployment if you think there is a need. - -## Tech - -- Strings are located in json files: https://github.com/Trustroots/trustroots/tree/master/public/locales -- Is it possible to get Weblate to integrate new languages automatically? - -Please see the [Developer’s guide to internationalization](./i18n.md) for more details. diff --git a/docs/index.md b/docs/index.md index 684fbb812a..e72aa040f6 100644 --- a/docs/index.md +++ b/docs/index.md @@ -13,68 +13,5 @@ title: Trustroots Team Guide ## Becoming a volunteer -[_Become a volunteer and make a difference!_](Volunteering.md) +[Become a volunteer](Volunteering.md) - diff --git a/modules/support/client/components/SupportPage.component.js b/modules/support/client/components/SupportPage.component.js index 63d3727ea2..fc90ac9432 100644 --- a/modules/support/client/components/SupportPage.component.js +++ b/modules/support/client/components/SupportPage.component.js @@ -37,7 +37,7 @@ export default function SupportPage({ user }) { {t('Frequently Asked Questions')}
  • - {t('Bugs & Features')} + {t('Report a bug')}
    • {user && (
  • diff --git a/modules/tribes/client/components/TribesList.js b/modules/tribes/client/components/TribesList.js index 650d8c7916..41cb9d9c37 100644 --- a/modules/tribes/client/components/TribesList.js +++ b/modules/tribes/client/components/TribesList.js @@ -41,9 +41,6 @@ export default function TribesList({ tribes, user, onMembershipUpdated }) { /> ))} - - - ); }