Merge pull request #7 from poyrazavsever/master

Dökümantasyon: Katkı Süreçlerini Standartlaştırma
This commit is contained in:
Yusuf İpek
2026-04-22 14:31:17 +03:00
committed by GitHub
9 changed files with 330 additions and 0 deletions
+45
View File
@@ -0,0 +1,45 @@
---
name: Bug report
about: Report a reproducible bug in OpenFrame
title: "bug: "
labels: [bug]
assignees: []
---
## Bug summary
What went wrong?
## Steps to reproduce
1.
2.
3.
## Expected behavior
What should have happened?
## Actual behavior
What happened instead?
## Environment
- OpenFrame version/branch:
- Bun version:
- Node version:
- Browser (if UI issue):
- OS:
## Relevant logs/errors (attach files)
Attach error logs, stack traces, or API error outputs as files/images. If needed, you can add a short summary here.
## Impact (optional)
Who is affected and how severe is the impact?
## Additional context
Screenshots, recordings, or links.
+5
View File
@@ -0,0 +1,5 @@
blank_issues_enabled: true
contact_links:
- name: Questions and contribution help
url: https://github.com/yusufipk/OpenFrame/blob/master/CONTRIBUTING.md
about: Use issues for actionable tasks; for questions, include context and expected outcome.
+33
View File
@@ -0,0 +1,33 @@
---
name: Feature request
about: Suggest an improvement for OpenFrame
title: "feat: "
labels: [enhancement]
assignees: []
---
## Problem statement
What problem are you trying to solve?
## Proposed solution
What do you want to happen?
## Alternatives considered
What alternatives did you evaluate?
## Success criteria (optional)
How will we know this request is successful?
Describe 1-3 concrete outcomes.
## Non-goals (optional)
What is explicitly out of scope?
## Additional context
Mockups, examples, or references.
+51
View File
@@ -0,0 +1,51 @@
## Summary
<!-- Explain what changed in this PR. -->
## Why
<!-- Explain the problem this PR solves. -->
## Scope
What areas are affected?
- [ ] API routes
- [ ] Auth / access control
- [ ] Database schema / migration
- [ ] UI / UX
- [ ] Documentation
- [ ] Other
## Before opening PR
- [ ] I have read [CONTRIBUTING.md](CONTRIBUTING.md) and followed repository conventions.
- [ ] I ran `bun run check`.
- [ ] I ran `bun run db:generate` if `prisma/schema.prisma` changed.
- [ ] I manually tested affected flows.
- [ ] PR title follows Conventional Commits (`type(scope): summary`).
- [ ] I used `successResponse` / `apiErrors` for API response changes.
- [ ] I used `auth()` and shared access checks (`checkProjectAccess` / `checkWorkspaceAccess`) where relevant.
- [ ] I updated docs when behavior changed.
- [ ] No secrets or unrelated file changes are included.
Validation notes:
```text
Paste command output or manual test notes here.
```
## Breaking changes
- [ ] No breaking changes
- [ ] This PR introduces a breaking change (describe below)
<!-- If breaking, explain migration path. -->
## Database / migration notes
<!-- If schema changed, summarize migration impact. -->
## Screenshots / examples (if relevant)
<!-- Add screenshots or API request/response examples. -->
+2
View File
@@ -0,0 +1,2 @@
# Global default owners
* @yusufipk
+71
View File
@@ -0,0 +1,71 @@
# Code of Conduct
## Our Pledge
We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
## Our Standards
Examples of behavior that contributes to a positive environment include:
- Demonstrating empathy and kindness toward other people
- Being respectful of differing opinions, viewpoints, and experiences
- Giving and gracefully accepting constructive feedback
- Taking responsibility, apologizing to those affected by mistakes, and learning from the experience
- Focusing on what is best not just for us as individuals, but for the overall community
Examples of unacceptable behavior include:
- The use of sexualized language or imagery, and sexual attention or advances of any kind
- Trolling, insulting or derogatory comments, and personal or political attacks
- Public or private harassment
- Publishing others' private information, such as a physical or email address, without explicit permission
- Other conduct which could reasonably be considered inappropriate in a professional setting
## Enforcement Responsibilities
Project maintainers are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to behavior they deem inappropriate, threatening, offensive, or harmful.
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 with this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
## Scope
This Code of Conduct applies within all community spaces and also applies when an individual is officially representing the project in public spaces. Examples include using an official project email address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
## Enforcement Guidelines
Maintainers will follow these Community Impact Guidelines in determining consequences:
### 1. Correction
Community Impact: Use of inappropriate language or other behavior deemed unprofessional or unwelcome.
Consequence: A private, written warning from maintainers, providing clarity around the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
### 2. Warning
Community Impact: A violation through a single incident or series of actions.
Consequence: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction, for a specified period. Violating these terms may lead to a temporary or permanent ban.
### 3. Temporary Ban
Community Impact: A serious violation of community standards, including sustained inappropriate behavior.
Consequence: A temporary ban from any interaction or public communication with the community for a specified period. No public or private interaction with the people involved is allowed during this period. Violating these terms may lead to a permanent ban.
### 4. Permanent Ban
Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
Consequence: A permanent ban from any sort of public interaction within the project community.
## Attribution
This Code of Conduct is adapted from the Contributor Covenant, version 3.0:
- https://www.contributor-covenant.org/version/3/0/code_of_conduct/
Community Impact Guidelines were inspired by Mozilla's code of conduct enforcement ladder.
+86
View File
@@ -0,0 +1,86 @@
# Contributing to OpenFrame
Thanks for taking the time to contribute.
This guide covers setup, PR expectations, and required conventions.
## Local setup
1. Install dependencies.
```bash
bun install
```
2. Copy environment variables.
```bash
cp .env.example .env
```
3. Generate Prisma client.
```bash
bun run db:generate
```
4. Run validation.
```bash
bun run check
```
## Contribution workflow
1. Fork and create a branch from `master`.
2. Keep changes focused on one logical concern.
3. Follow repository conventions in this file.
4. Run required checks locally.
5. Open a PR with a clear summary and checklist.
## Branch naming
- `feature/<short-topic>`
- `fix/<short-topic>`
- `docs/<short-topic>`
- `refactor/<short-topic>`
- `chore/<short-topic>`
## Commit and PR title standard
Use Conventional Commits with this pattern:
```text
type(scope): short summary
```
## Required checks before opening a PR
- Run `bun run check`.
- If `prisma/schema.prisma` changed, run `bun run db:generate`.
- Ensure no unrelated file changes are included.
- Ensure no secrets or private keys are committed.
- Update docs when behavior changes.
## Project conventions (must follow)
- Use Bun commands only.
- Server-side session reads must use `auth()` from [lib/auth.ts](lib/auth.ts).
- Access control should use `checkProjectAccess()` / `checkWorkspaceAccess()`.
- API responses should use `successResponse` / `apiErrors` from [lib/api-response.ts](lib/api-response.ts).
- In App Router dynamic routes, keep `params` typed as `Promise<...>` and use `await params`.
- For multi-step DB writes, use Prisma transactions.
- Prefer backward-compatible API changes unless a breaking change is explicitly requested.
- Prefer `@/` imports when available.
## Security issues
Do not open public issues for vulnerabilities.
Follow [SECURITY.md](SECURITY.md).
## Code of conduct
Follow [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md).
## Need help?
If you are unsure where to start, open an issue with context and a proposed approach.
+8
View File
@@ -151,3 +151,11 @@ bun run check
```
Feature flags and self-hosting environment variables are documented in `.env.example` and `.env.docker.example`.
## Contributing
Contributions are welcome.
- Read [CONTRIBUTING.md](CONTRIBUTING.md) for workflow, conventions, and PR requirements.
- Use [SECURITY.md](SECURITY.md) for responsible vulnerability reporting.
- Follow [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) in all project interactions.
+29
View File
@@ -0,0 +1,29 @@
# Security Policy
## Supported Versions
OpenFrame is under active development.
Security fixes are prioritized for the latest code on `master` and recent release tags (if available).
## Reporting a Vulnerability
Please do not report security vulnerabilities in public issues.
Report vulnerabilities by email to info@open-frame.net.
Include as much detail as possible:
- Affected area (API route, auth flow, upload flow, etc.)
- Reproduction steps
- Proof of concept (if available)
- Potential impact
- Suggested remediation (optional)
## What to Expect
After a private report is submitted:
1. Maintainers acknowledge receipt.
2. Impact and exploitability are triaged.
3. A fix is prepared and validated.
4. Disclosure timing is coordinated.
5. Credits are given when appropriate.