fix(dashboard): calculate usability percentage from real evaluator data

.firebaserc

@@ -17,4 +17,4 @@
   },
   "etags": {},
   "dataconnectEmulatorConfig": {}
-}
+}

.github/workflows/i18n-diff-guard.yml

@@ -27,7 +27,7 @@ jobs:
       - name: Run i18n diff guard
         id: i18n_check
         continue-on-error: true
-        run: node i18n-diff-guard.js
+        run: node i18n-diff-guard.mjs
 
       - name: Post PR comment on failure
         if: steps.i18n_check.outcome == 'failure'

.husky/pre-commit

@@ -1,5 +1,5 @@
 #!/usr/bin/env sh
 echo "🔍 running pre-commit hook"
-node i18n-diff-guard.js
+node i18n-diff-guard.mjs
 npm run test
 npx lint-staged

CONTRIBUTING.md

@@ -11,11 +11,15 @@ Thank you for your interest in contributing to RUXAILAB! This document provides
 - [Code Standards](#code-standards)
 - [Testing](#testing)
 - [Reporting Issues](#reporting-issues)
+- [Issue Labeling Guide](#issue-labeling-guide)
+- [Pre-commit Hooks](#pre-commit-hooks)
 
 ## Code of Conduct
 
 We are committed to providing a welcoming and inclusive environment for all contributors. Please be respectful and constructive in all interactions.
 
+For Code of Conduct discussions and support, please use our Discord channel: https://discord.com/channels/1209902463239593984/1209902463713288293
+
 ## Getting Started
 
 RUXAILAB is a Vue.js-based platform for usability testing and heuristic evaluation. Before contributing, familiarize yourself with:
@@ -171,22 +175,22 @@ Then create a Pull Request on GitHub:
 - Target the `develop` branch
 - Provide a clear description of your changes
 - Reference any related issues
+- Keep at most **2 open Pull Requests** per contributor at any time (additional PRs are automatically closed by workflow)
 - Wait for review and address any feedback
 
 ## Code Standards
 
 ### Formatting
 
-We use **Prettier** for code formatting. Configuration is in `.prettierrc`.
+We use **Prettier** for code formatting. Prettier is automatically applied through pre-commit hooks, so you don't need to manually format most of the time.
 
 ```bash
-# Format all files
-npm run format
-
-# Check formatting
-npm run format:check
+# If needed, manually format files
+npx prettier --write src/your-file.vue
 ```
 
+See [Code Formatting Rules](#code-formatting-rules) section below for detailed information about formatting standards.
+
 ### Linting
 
 We use **ESLint** for code quality. Configuration is in `eslint.config.mjs`.
@@ -199,6 +203,8 @@ npm run lint
 npm run lint:fix
 ```
 
+See [Code Formatting Rules](#code-formatting-rules) section below for detailed ESLint configuration information.
+
 ### Vue.js Best Practices
 
 - Use Composition API for new components
@@ -255,6 +261,8 @@ npm run test:e2e:headed
 
 ## Reporting Issues
 
+Each contributor may have a maximum of **5 open issues** at a time.
+
 ### Bug Reports
 
 When reporting bugs, please include:
@@ -282,7 +290,270 @@ Use the [Feature Request template](https://github.com/uramakilab/remote-usabilit
 
 For questions or general discussion, use [GitHub Discussions](https://github.com/uramakilab/remote-usability-lab/discussions).
 
-## Additional Resources
+## Issue Labeling Guide
+
+Issues in RUXAILAB are automatically labeled based on the issue title format and content. Understanding how labels work helps with issue organization and discoverability.
+
+### Auto-Applied Labels
+
+Issues are automatically labeled when opened or edited. Here's how to use labels effectively:
+
+#### 1. **Issue Type Labels** (Auto-applied based on title format)
+
+Use conventional commit prefixes in your issue title to get proper type labels:
+
+| Prefix      | Label           | Usage                          |
+| ----------- | --------------- | ------------------------------ |
+| `feat:`     | `feature`       | New features or enhancements   |
+| `fix:`      | `bug`           | Bug reports and fixes          |
+| `docs:`     | `documentation` | Documentation improvements     |
+| `refactor:` | `refactor`      | Code refactoring               |
+| `test:`     | `tests`         | Test additions or improvements |
+| `perf:`     | `performance`   | Performance improvements       |
+| `ci:`       | `ci`            | CI/CD workflow changes         |
+| `chore:`    | `chore`         | Maintenance tasks              |
+| `build:`    | `build`         | Build system changes           |
+| `style:`    | `style`         | Formatting and style changes   |
+
+**Examples:**
+
+- ✅ `feat: add dark mode support` → gets `feature` label
+- ✅ `fix: correct navbar alignment` → gets `bug` label
+- ✅ `docs: update installation guide` → gets `documentation` label
+- ❌ `Add dark mode support` → no type label (ambiguous)
+
+#### 2. **User Type Labels** (Auto-applied based on user role)
+
+- **`maintainer-issue`** - Issues opened by maintainers and team members
+- **`community-issue`** - Issues opened by community contributors
+
+These labels help maintainers identify which issues come from the core team vs. the community.
+
+#### 3. **Other Auto-Applied Labels**
+
+- **`bug`** - Auto-applied for bug reports (if title contains `[bug]`, `🐞`, or matches bug template)
+- **`help`** - Auto-applied if issue title or body mentions "help wanted" or "need help"
+
+#### 4. **Manual Labels** (Applied by maintainers)
+
+Some labels are applied manually by maintainers:
+
+- **`good first issue`** - Good starting points for new contributors
+- **`blocked`** - Issues blocked by other work
+- **`wontfix`** - Issues that won't be worked on
+- **`duplicate`** - Duplicate of another issue
+- **`priority-high`** / **`priority-medium`** / **`priority-low`** - Issue priority levels
+- **`security`** - Security-related issues
+- **`dependencies`** - Dependency update issues
+
+### Writing Issues with Proper Labels
+
+To ensure your issue gets the correct labels:
+
+1. **Use conventional commit format** for the title:
+
+   ```
+   <type>(<scope>): <description>
+   ```
+
+   - `type`: One of feat, fix, docs, refactor, test, perf, ci, chore, build, style
+   - `scope` (optional): Component or area affected, e.g., `auth`, `dashboard`
+   - `description`: Brief description
+
+   Examples:
+   - `feat(auth): add social login providers`
+   - `fix(ux-creation): resolve template duplication bug`
+   - `docs(api): update Firebase setup instructions`
+
+2. **Use issue templates**: GitHub provides templates for bug reports and feature requests that auto-apply some labels
+
+3. **Be clear and descriptive**: This helps maintainers understand the issue scope and apply additional labels correctly
+
+## Pre-commit Hooks
+
+This project uses **Husky** and **lint-staged** to automatically format and lint code before each commit. This ensures code quality standards are maintained.
+
+### How It Works
+
+When you commit changes, the following automatically runs:
+
+1. **Husky** intercepts the commit
+2. **lint-staged** runs linting and formatting on staged files:
+   - **ESLint** checks for code quality issues
+   - **Prettier** formats code for consistency
+
+### Pre-commit Hook Rules
+
+```bash
+# Files matching src/**/*.{js,vue} will have:
+- eslint --fix         # Auto-fix ESLint issues
+- prettier --write     # Auto-format with Prettier
+```
+
+### Setup
+
+Pre-commit hooks are set up automatically when you run:
+
+```bash
+npm install
+```
+
+This installs Husky and sets up the `.husky/pre-commit` hook.
+
+### If Hooks Don't Run
+
+If pre-commit hooks aren't running, initialize Husky:
+
+```bash
+npx husky install
+```
+
+### Skipping Pre-commit Hooks (Not Recommended)
+
+If you absolutely need to skip the pre-commit hook, use:
+
+```bash
+git commit --no-verify
+```
+
+⚠️ **Warning**: This bypasses code quality checks. Avoid this in production code.
+
+### Manual Code Quality Checks
+
+You can also manually run these commands:
+
+```bash
+# Check for ESLint issues
+npm run lint
+
+# Auto-fix ESLint issues
+npm run lint:fix
+
+# Format code with Prettier (if needed manually)
+npm run format
+
+# Or use Prettier directly to format specific files
+npx prettier --write src/your-file.vue
+```
+
+### Code Formatting Rules
+
+#### Prettier Configuration
+
+RUXAILAB uses Prettier for consistent code formatting. While there's no `.prettierrc` file, Prettier uses sensible defaults:
+
+- **Print Width**: 80 characters
+- **Tabs**: 2 spaces (no tabs)
+- **Quotes**: Double quotes for strings
+- **Semicolons**: Enabled
+- **Trailing Commas**: ES5 style (where valid in older JS)
+- **Arrow Functions**: Always add parentheses around parameters
+
+#### ESLint Configuration
+
+ESLint configuration is in `eslint.config.mjs`:
+
+- **Parser**: Uses Vue 3 template parser with Babel support
+- **Plugins**: Vue, Vuetify, Vue I18n
+- **Extends**: Vue recommended rules, Vuetify recommendations, Prettier integration
+- **Browsers Globals**: Browser APIs are available
+
+Key rules enforced:
+
+- Vue 3-specific syntax requirements
+- Proper component structure
+- No unused variables
+- Proper i18n usage
+
+### Vue.js Code Style Examples
+
+#### ✅ Good Component Structure
+
+```vue
+<template>
+  <div class="card">
+    <h2>{{ title }}</h2>
+    <p>{{ description }}</p>
+    <v-btn @click="handleClick">{{ buttonText }}</v-btn>
+  </div>
+</template>
+
+<script setup>
+import { computed, ref } from 'vue'
+
+const props = defineProps({
+  title: {
+    type: String,
+    required: true,
+  },
+  description: {
+    type: String,
+    default: '',
+  },
+})
+
+const emit = defineEmits(['click'])
+
+const count = ref(0)
+
+const buttonText = computed(() => {
+  return count.value > 0 ? `Clicked ${count.value} times` : 'Click me'
+})
+
+function handleClick() {
+  count.value++
+  emit('click', count.value)
+}
+</script>
+
+<style scoped>
+.card {
+  padding: 1rem;
+  border: 1px solid var(--divider);
+  border-radius: 4px;
+}
+</style>
+```
+
+#### ✅ Good JavaScript Style
+
+```javascript
+// Use const by default, let if you need to reassign
+const API_ENDPOINT = 'https://api.example.com'
+let selectedUser = null
+
+// Arrow functions for callbacks
+const items = data.map((item) => ({
+  ...item,
+  formatted: item.value.toUpperCase(),
+}))
+
+// Destructuring in function parameters
+function processData({ name, age, email }) {
+  return {
+    name: name.trim(),
+    age: parseInt(age),
+    email: email.toLowerCase(),
+  }
+}
+
+// Use template literals
+const message = `Hello, ${userName}! You have ${messageCount} new messages.`
+
+// Async/await for promises
+async function fetchUserData(userId) {
+  try {
+    const response = await fetch(`/api/users/${userId}`)
+    if (!response.ok) {
+      throw new Error(`API error: ${response.status}`)
+    }
+    return await response.json()
+  } catch (error) {
+    console.error('Failed to fetch user:', error)
+    throw error
+  }
+}
+```
 
 - [README.md](README.md) - Project overview and setup
 - [Vue.js Documentation](https://vuejs.org/)

README.md

@@ -40,7 +40,11 @@ UX Remote LAB provides a collaborative environment for creators to share their p
 - [Request a Feature 🚀](https://github.com/uramakilab/remote-usability-lab/issues/new)
 - [Ask a Question 🤗](https://github.com/uramakilab/remote-usability-lab/discussions)
 
-For commercial support, academic collaborations, and answers to common questions, please use [Get Support]() to contact us.
+For commercial support, academic collaborations, and answers to common questions, please contact us by one of our communications channels:
+
+- [Discord Server](https://discord.gg/YnkDk9BNYK)
+- [Discussions](https://github.com/ruxailab/RUXAILAB/discussions)
+- Email: `ruxailab@gmail.com`
 
 ### Development Environment
 
@@ -205,4 +209,4 @@ Visit `http://localhost:5000` in your browser to access the UX Remote LAB platfo
 
 ## License
 
-MIT © [RUXAILAB](https://github.com/uramakilab/remote-usability-lab)
+MIT © [RUXAILAB](https://github.com/ruxailab/RUXAILAB)

functions/.env.example

@@ -4,4 +4,5 @@ SMTP_USER=
 SMTP_PASS=
 SMTP_SECURE=
 SITE_URL=
-RUXAILAB_FUNCTIONS_REGION=
+RUXAILAB_FUNCTIONS_REGION=
+EYE_LAB_CORS_ORIGINS=

functions/.gitignore

@@ -1 +1,6 @@
 node_modules/
+
+# Functions env files
+.env
+.env.*
+!.env.example