Open Source Project Management

[gmillinger]

I have been thinking through the imixs-micro project charter and found many gaps in my understanding about defining and managing an open-source project.

The methodology I use for product development is typically mixed with traditional and agile methods but always using an iterative development cycle.

The is how I typically execute a project:

• Receive or develop a project charter with stakeholder goals, requirements, constraints, and schedule.
• For product development, create a multi-phase roadmap to satisfy the project charter.
• Breakdown the first roadmap phase into milestones identifying deliverables for each milestone and acceptance criteria.
• Assemble the team and kick-off the project as a group to baseline terminology and methodology so everyone has a common understanding of how to work together.
• Post the deliverables on a collaboration intranet for Milestone 1 and allow the team to pick deliverables according to their specialty (i.e. front-end, back-end, UX).
• Coordinate the iterative cycle at an agreed on interval until we accomplish the milestone.
• Repeat until the phase is completed.

In an open-source project how is this all documented and managed to keep contributors working toward an outcome? I have looked at many open-source projects on Github and see common structure to the repositories but not much documentation and planning that steers the project contributors toward a goal. What are the best practices? Are there any books or references where I can learn the details?

Most importantly, what is your philosophy on this and how you would like projects such as imixs-micro to be managed?

[rsoika]

Open Source does not define how a project is managed and organized. So its up to the project team to define its own methodology. Github is just a code repository that provides some tools to organize a project. For example you can define milestones and labels (tags) to organize your issues. Git in general provides the concept of branches that allow you to develop on different versions, feature streams or bugfixes in parallel in different teams. There are many many ways to organize your dev-process.

Further more I use Maven as the build tool. With Github Actions you can define workflows to automatically run tests, create new releases or build other artifacts - e.g. you can define a job that automatically builds a Image for a Raspberry Pi each time someone commits new changes.

If the team is very small - like this one - complex dev-processes will not necessarily simplify things ;-)

[gmillinger]

"If the team is very small - like this one - complex dev-processes will not necessarily simplify things" Yes I agree. I will still create a project charter and requirements to add to docs to keep me on track. Something about getting old has affected my memory and documenting some things will help keep me on focused.

I am thinking about creating a private repo for the bigger project of re-developing my current platform. If I do, I will add you do that repo so you can have a look if you choose.