^home

Project Management

#Bootstrapping

Once a project is started, the following will be created:

Then everyone involved with the project will be sent an e-mail containing more information on the project and the resources mentioned above.

Everyone involved will be given access to the project mailing lists by their e-mail address. If being part of the discussions is all you need you are fine. Just subscribe to the mailing lists and get on with your life.

But if you'll need to access the mailing list archives, project wiki, task tracker and code repositories you'll need to create a Sourcehut[1] contributor account. Registration is very easy, quick and free. After registering send your username to the project manager so that you'll be given access.

[1]: Our preferred software project development & management service. Something like Github but simpler.

#Project Wikis

Wikis contain project documentations.

A project's wiki will be accessible via https://git.sr.ht/~gwn/<proj-id>-wiki

The following information will be available from the outset:

And the following information will be added as soon as ready:

RFCs should be introduced & discussed in the project's discussion mailing list then transferred to the wiki when ready.

#Task Trackers

Task trackers are used for tracking todo items such as bugs and features.

A project's task tracker will be accessible via https://todo.sr.ht/~gwn/<proj-id>

Initially one task will be created for each step of the Project Lifecycle starting with the "Requirements Analysis" step up until the "Determine Atomic Deliverables" step.

As soon as the "Determining Atomic Deliverables" task is dealt with, those atomic deliverables will be added as new tasks.

But irrespective of all that anyone who has access to a tracker can create tasks anytime.

One important note is that clients / partners are discouraged from filing bug reports & feature requests directly to the task trackers. Instead they are encouraged to post them to the project's discussion mailing list. If & when the bug report / feature request is confirmed then a project manager or a developer can create a task in the tracker. This flow might be enforced from time to time by giving clients / partners only read & comment permissions (but not submission) to task trackers. You can check out a relevant Sourcehut blog post for get more information on this approach.

Detailed documentation of the task trackers can be found in the Sourcehut todo wiki.

#Mailing Lists

Mailing lists are used for announcements, general discussion, bug reports, feature requests, development discussion and patch submissions.

There will be 3 lists per project:

Detailed documentation for the mailing lists can be found in the Sourcehut mailing list documentation.

#Meetings

Anyone should be able request meetings from each other at any time as long as they follow the below guidelines:

Meeting logs will be produced and saved into the project wiki by our members for most meetings.

#Communication Preferences

Our preferred communication channels are mailing lists & task trackers.

General discussion, help requests, Q&As, bug reports and feature requests can be made in a project's discussion mailing list. It's also ok to make use of IM apps for banter & voice exchanges but the important & actionable stuff should always go to the mailing lists. There should be no expectation from us to follow through an IM feed. Only post stuff there that you can afford to be ignored. We will not cherry pick requirements & issues from Telegram histories.

Bug reports & feature requests are required to be communicated via the discussion mailing list or the task tracker (if applicable). They will be ignored when communicated via phone calls / instant messages.

Phone calls are ok as long as an immediate exchange is needed. Our phones will be on and we will always try to be reachable as long as you don't abuse this.

We don't guarantee enabling IM notifications on our phones so when you need to reach us immediately opt for phone calls instead of text messages.

Scheduled meetings are ok when they make sense. We have two general rules:

#Reporting

By default we post weekly logs to the project's announcement mailing list to communicate status.

Depending on the circumstances other kinds of reports such as daily logs, monthly retrospectives, etc can be agreed on.

#Code Repositories

Once a project is accepted, one or more code repositories will be created with names identical to or derivative of the project code name. So for a project with the code name "dummy" we can have repositories such as "dummy", "dummy-api", "dummy-client" etc. They would be reachable via the following URLs:

And with the Git protocol:

The list of code repositories can be seen in the project's source index page at https://sr.ht/~gwn/<proj-id>/sources

The repositories may or may not be accessible to clients & partners depending on the nature of the related arrangement.

The Sourcehut Git web interface supports patch submissions via forms that can be used by developers who are used to the "pull request" paradigm and not comfortable with the Git send-email method. See here for instructions.

#Project Lifecycle

  1. Collaboration request
  2. Bootstrapping
  3. Requirements analysis
  4. Technical analysis
  5. Determining the acceptance criteria
  6. Determining the milestones
  7. Estimation
  8. Agreeing on the compensation method & numbers
  9. Determining the product owner
  10. Determining atomic deliverables
  11. Implementation
  12. Quality assurance
  13. Feedback gathering
  14. Bugfixes and revisions
  15. Go to 12

#Collaboration Request

A project comes to life when a client / partner approaches us with a collaboration request. We require this request to be formalized with an email containing the details specified in the Hire page.

#Bootstrapping

A wiki, an task tracker, mailing lists and one or more code repositories are created for the project.

Client / partner is sent the link to the project wiki.

#Requirements Analysis

Requirements analysis is a process with the goal of understanding & clarifying the motivations behind & expected outcomes of a project by interviewing all the stakeholders of the project to understand their needs, resolving any conflicts and in the end produce a document called a "requirements specification" that all the stakeholders can agree on.

#Technical Analysis

Technical analysis is the process of analyzing the requirements from a technical perspective to evaluate feasibility, identify potential trade-offs and risks. The goal is to produce a document called a "technical specification" that loosely specifies a tech stack, a system architecture and a development roadmap.

Findings made during the technical analysis may require changes in the requirements.

#Determining the Acceptance Criteria

Unambiguous acceptance criteria makes it possible for the developers to make implementations with minimal friction and for the clients to validate the completeness & correctness of those implementations.

It's important to determine them as specifically and as early as possible to avoid otherwise redundant iterations.

#Determining the Milestones

There are multiple atomic deliverables in a typical project. Deliverables change, and new ones are added over time. But still they should be roughly identifiable in the beginning of a project.

Some deliverables can be dealt with in parallel, some can not as they may depend on another deliverable or something else. And often a deliverable is postponed even if it can be dealt with in parallel to others simply because of its low priority.

Milestones help prioritization by grouping atomic deliverables together according to the project roadmap.

#Estimation

Once the acceptance criteria are clear and the milestones are set, developers are able to provide estimated delivery dates.

Not all estimations can have the same confidence rate. They depend on the nature of the requirements.

#Agreeing on the Compensation Method & Numbers

Compensation methods: Cash, revenue sharing, stocks

#Determining the Product Owner

All projects will be assigned a single product owner who will be the main responsible. There will also be a "main contact" chosen from the client's / partner's side.

Those two people will be responsible of getting things going.

#Determining Atomic Deliverables

WIP

#Implementation

WIP

#Quality Assurance

WIP

#Feedback Gathering

WIP

#Bugfixes and Revisions

WIP