gitpoint / gitpoint/git-point

Discussion: Internal - Project & Releases management

オープン
#626 コメント 3 件 リアクション 2 件 担当者 0 名 GitHub で見る
discussion
主要言語
JavaScript
スター
4.8k
フォーク
771
PR マージ指標
30日以内にマージされた PR はありません

説明

Echoing #569, I would like if we could talk about our project management and lay out some guidelines here, in order to streamline the releases and be able to deliver new versions more quickly.

Here's my take on the subject:

#### Deprecate milestones

In order to avoid confusions, we should only be using the [GitHub project management](https://github.com/gitpoint/git-point/projects) interface to handle releases.

Milestones should be removed.

#### Project management usage

Only issues should be referenced in cards, no pull-requests.

Proposed columns:

* Proposed: Issues proposed for the release. Inclusion to be discussed.
* Todo: Issues approved & pending for this release
* In progress: Issues that were Todo and now have a WIP PR
* Ready for review: Issues that were Todo and now have a ready PR
* Completed: Issues that were Todo and are now merged in

#### Release manager

I think it would be really nice if we designate a release manager by release, to ease things up on @housseindjirdeh.

The RM responsibility would basically be:

* Discuss & move items from "Proposed" to "Todo" or other when a consensus have been reached
* Make sure the project management interface stays up to date for his release
* Revive pending PRs/Issues that needs to be addressed when they go silent for too long

#### Release QA

Either the RM, or another person should be tasked for QA during the release development.
This person would regularly test the app for regressions and post comments / new issues if needed.

@housseindjirdeh would be responsible for the last QA testing before the new version is pushed to stores.

The QA should be performed on both Android & iOS. (and we can have multiple QA members).

Here, I'm not sure if we want to change the QA team for every release, or if some people may want to take this role more permanently.

### Releases branches

This have been discussed on gitter, but I'm not sure we have decided yet how we could better use our git branches or tag to help with this. I personally lack the git-project management knowhow to propose something.

This needs to be addressed in order to be able to have real semantical releases (no more new features in patch releases)

How do **you** feel about this? What would you change?

コントリビューションガイド

コントリビューションガイドを開く

調査の方向性

#569 の議論と、ここで参照されている GitHub Projects インターフェースを確認してください。提案されているマイルストーン、release-manager、QA、および branching のガイドラインを検討し、そのうえでプロセス変更と release-branch の方針について合意形成を図ってください。完了とは、実装パッチではなく、プロジェクトが文書化された決定事項に合意していることを意味します。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
git, github
領域
release
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
15/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。