website-and-documentation/content/en/docs/edp/forgejo/project-mgmt.md

78 lines
4.1 KiB
Markdown

---
title: "Project Management"
linkTitle: "Forgejo Project Mgmt"
weight: 50
description: >
Organization-level project and issue management (discontinued feature)
---
{{% alert title="Discontinued Feature" color="warning" %}}
This feature was implemented at a prototype level but never reached production readiness. Development was discontinued in favor of other platform priorities.
{{% /alert %}}
## Overview
This was an attempt to extend Forgejo's project and issue management capabilities beyond the repository level. The goal was to enable organizations and users to create projects and issues that could span multiple repositories or exist independently of any repository.
## Problem Statement
Forgejo's issue management is repository-centered. While this works well for code-specific issues, it creates challenges for broader project management:
* **Cross-repository work**: Tasks often span multiple repositories but must be artificially tied to one
* **Non-code projects**: Some projects don't map cleanly to a repository (e.g., planning, documentation initiatives)
* **Related repositories**: Symbiotically related repos would benefit from shared issue tracking
Real-world examples:
* Upstream: [forgejo-actions-feature-requests](https://code.forgejo.org/forgejo/forgejo-actions-feature-requests) - arguably doesn't need repository/code functionality
* EDP: [infra-deploy](https://edp.buildth.ing/DevFW/infra-deploy) and [infra-catalogue](https://edp.buildth.ing/DevFW/infra-catalogue) - symbiotically related projects
## Implementation Status
**Status**: Prototype level - basic operations work but not production-ready
**What was built:**
* Projects can be created at the organization/user level (not tied to repositories)
* Issues can be created within these organization-level projects
* Issues can be moved between columns within any projects
* Basic Create and View Issue pages function without errors
**What was incomplete:**
* Several features on Create/View pages disabled rather than adapted, e.g. due dates
* Repository-specific features (tags, code reviews, etc.) not resolved for org-level context
* Broader issue management features not yet functional
## Discontinuation
Development was discontinued due to:
* Project priorities shifted to other platform features
* Scope of remaining work deemed too large for the anticipated value
* Concerns about maintaining a custom feature divergent from upstream Forgejo
## Repository
**Code**: [edp-forgejo](https://edp.buildth.ing/DevFW/edp-forgejo) (Remark: You must be logged into edp.buildth.ing as the repo is internal)
This is a fork of upstream Forgejo with the organization-level project management changes. The fork is based on Forgejo v11.x (upstream has progressed to at least v13.x).
**Implementation**: Changes to both UI (in TypeScript) and server-side (Golang) functionality.
## Technical Approach
The implementation involved:
* Minimally modifying Forgejo's data model to associate projects with organizations/users instead of repositories
* Adapting issue creation and display logic to work without repository context
* Addressing repository-specific settings (labels, milestones, code review integration) for org-level issues
* UI changes to support project creation and issue management at the organization level
## Integration Points
This feature was developed as an isolated extension to Forgejo. Its code is within the `edp-forgejo` repository alongside other EDP updates - such as magenta colour scheme - but in terms of functionality has minimal overlap/links with other EDP components.
## Lessons Learned
* Repository-centric design is deeply embedded in Forgejo's architecture
* Maintaining custom features in a fork creates significant maintenance burden
* The scope of fully-functional cross-repository project management is substantial
* This is related to Issues and Repositories being two of the most extensive features in Forgejo
* Alternative approaches (using dedicated project management tools, or simply 'shell' repositories) may be more sustainable
* Clear buy-in is needed for the long term in order to make a change like this viable