Renovate Development Board

Description

Since the inception of the Cotheca Project, GitHub has refined its Projects feature into a more robust Project Management suite. The current implementation of the Development practices remains practical, solid, and flexible. However, there have been some areas for the initial The Cotheca Docs Release milestone where it has been somewhat difficult to track progress. From a Project Management point of view, this is concerning. The truth is that I have not been able to keep up as much as I have wished on setting up this documentation resource. Obviously, that's part of the point of the whole Cotheca Project.

There are so many things that I want to accomplish for these code libraries, for both my open source work and for personal closed source work. But the Cotheca Project isn't just about the code.

While the Cotheca Project talks about making code reusable, the truth is that setting an organizational foundation is required for any projects, and that on its own is one of the points about the project. The bureaucratic side of Software Development is highly needed and should be in place in each organization. Any code author knows that in most organizations, that doesn't happen.

By pointing this out within an organization, you can even be marked or pointed out as the "inexperienced" junior who has no idea how the "real" world programs and has utopian ideas on how the world should work, but can't happen due to a huge amount of reasons. This is not necessarily true. It might be true that it is too late for such an organization, but not for development in general. Whether it is in the name of practicality or just the denial of handling the overwhelming requirements for a proactive and future-proof development, the truth is that most code authors decide to cut this cornerstone for better development. And the thing is that I do believe in those utopian practices because it's exactly the experience of working on my own old projects after a while where I have no idea why I did what I did (I mean, I get the logic and the code, but not the actual why), or other projects that, of course, I can read through the code and will be able to understand how it works, but the point is that with proper practices I could have gotten started right away by just looking at documentation, diagrams, or any other knowledge resources, and have a pretty solid idea of what needs to be achieved within minutes, instead of spending days on trying to understand it by reading the code or stepping through it in a debugger. Ironically, most of the people who embrace the "documentation is the code" mentality (without actual documentation or comments in the code) are the same kind of people who struggle to integrate common third-party systems or libraries and later complain about how inconvenient the poor documentation for such a system is.

Well, that's exactly what the Cotheca Docs project is trying to provide: a re-usable framework of practices to unburden the bureaucratic side of Project Management while establishing good practices for the Cotheca Project as an organization from the start, rather than start developing things that aren't going to work as universally as they could, for the rest of the Cotheca Project.

With that said, I want to make an example out of this open source project, on how taking the proper measures can be overwhelming as they are for a code author. Because, honestly, this is not what I picture the project to be stuck on for over a year, and there are so many projects that I would prefer to be programming, instead of acting all bureaucratic, but I do believe these are necessary steps for solid projects, at Cotheca, on my personal projects, and hopefully for other people. Hopefully, this project gets enough grip so all this time and effort that I've put into these documents help someone or some organization not spend a year on this, but rather a fraction of that time by just adjusting these documents to their taste, or even better, to help me improve mine in their process of establishing their own. Even if we don't agree on the methodology, I might be able to find value in their work and adopt it too, just in the same way they could have found value in some part of this methodology. That's what Cotheca is about.

Possible Solution(s)

Remove individual projects for sprints. That doesn't mean that we stop working in iterations, but rather, how we integrate this on multiple repositories at once and how we can break projects into multiple iterations. Originally the idea behind the "Sprint" GitHub projects, was to track how long something was idle, under development or took to be completed.

GitHub has improved drastically the features within its Projects features to do this more efficiently.

The development board is going to be the one project used, but will implement different views and integrate practices to be able to track development stages for multiple projects or repositories at once, while still being able to track other management-related KPIs to make progress measurable for anyone.

We are going to re-adjust The Cotheca Docs Release milestone dates to be more realistic to the amount of work that it requires. Originally, the Cotheca Docs were supposed to be an outline to follow for projects, but ever since October 25th, 2022. It has housed so many different useful things and reference resources and have expanded more on the kind of information that it hosts. That's improved my overall project management skills and has centralized some reference files like templates and other notes and practices that it's been highly useful to me, and it's still only at a fraction of it's first deliverable state. So, I rather finish it to it's 1.0.0 version before even trying to develop actual code.

These changes should make more approachable to accomplish the goal of having a foundational resource for any software project.

Objectives

Please specify what the finished feature should accomplish (one or more objectives):

2024/4.2 Sprint is the last sprint project. Do not create any other sprint project.
[x] Create a feature branch 'feature-27-RenovateDevelopmentBoard' and link it to this issue.
[x] #28
- Status
- Field name: Status
- Field type: Single Select
- Options:
  - "New" (re-use existing one if available) This item hasn't been started.
  - "Blacklog" (re-use existing one if available) This item is actively being worked on
  - "Done" (re-use existing one if available) This item has been completed
- Priority
- Field name: Priority
- Field Type: Single select
- Options:
  - Urgent (re-use existing one if available)
  - High (re-use existing one if available)
  - Medium (re-use existing one if available)
  - Low (re-use existing one if available)
- Size
- Field name: Size
- Field type: Single select
- Options:
  - X-Large (re-use existing one if available)
  - Large (re-use existing one if available)
  - Medium (re-use existing one if available)
  - Small (re-use existing one if available)
  - Tiny (re-use existing one if available)
- Category
- Field name: Category
- Field type: Single select
- Options:
  - Product/Project Management (re-use existing one if available)
  - Feature (re-use existing one if available)
  - Bug (re-use existing one if available)
  - Support (re-use existing one if available)
- Target Date
- Field name: Target Date
- Field type: Date
- Start Date
- Field name: Start Date
- Field type: Date
- Sprint
- Field name: Sprint
- Field type: Iteration
- Iterations:
- 2-week long
- Start on closest Monday when the Cotheca Docs project was first created
- Add past sprints up to the present day
- Add at least the iterations a year quarter period for future (planned) sprints
[x] #29
- Remove current view "By size"
- Add "Current Sprint" view A simplified view of what's planned for the sprint, whether is going to be worked on, it's being currently worked on, or what has been completed.
- Renovate "Backlog" view Re-use existing Backlog view. This view will display all of the PBI's and reflect their development state. We are no longer going to have individual sprint projects, but rather we will use the GitHub projects feature of "iterations" instead. The backlog should integrate this feature in a meaningful informative way.
- Add "Sprint Blockers" view A quick view of items that aren't blocked, but are blocking other items and are part of the current sprint.
- Add "Roadmap" view The historic map of how items are planned and resolved, pretty much timeline view of the Backlog
- Renamed "By priority" view to "Prioritization" Same concept as the existing view, but in a better way to organize multiple projects and this should be a helpful tool alongside the new "Unassigned Blockers" view to organize PBI's in more efficient way.
- Add "Blockers" view A simplified view of the existing blockers, not just for the sprint, but for the whole Cotheca project. This are the PBI items that have been identified as dependencies that need to be resolved in order to let other backlog items to be completed. This should help identify bottle necks and prevent further blockers. Also, this would help break down large PBI items into smaller tasks, along with the use of milestones, this should report an accurate state of a milestone, and provide a realistic outlook for the completion of the milestone.
- Add "Unassigned Blockers" view A simplified way to identify blockers that hasn't been assigned or isn't being worked on. The overall goal is to keep this on zero items.
- Add "Unassigned" view Pretty much the same as the "backlog" view, but showing items that haven't being assigned. This will always have new issues and are a way to help contributors to identify and take on tasks.
[x] #32
[x] #31
- Assign the Development Board to existing item's projects
- Preserve old "Sprint" projects in existing items.
- Assign the Start Date and Target Date for the projects based on their original sprint
- Assign the latest sprint they fall into.
Merge into 'wip-1-InitialPractices' when completed. Do NOT merge into 'main' branch.

Additional Context

N/A

cotheca / docs