Re: [che-dev] GitHub Projects

[Tyler Jewell <tyler@xxxxxxxxxxx>]

Doing both strikes me as a lot of work.

We already struggle to keep the epics updated - think of this process:
1. We have pull requests for each task which have to be mapped to milestones.

2. Those PRs have to be cross-linked into each of the originating epics (they are not always by devs)

3. Those epics need to be cross-linked into any user-support tickets

4. And then we'd have to keep the project views up to date.

So the basic introduction of a new PR has a lot of cross-linking, and it would be virtually impossible for us to have devs all keep every cross link current all the time.

Tyler Jewell | CEO | tyler@​codenvy.​com | 9​78​.8​84​.53​55

On Sun, Sep 18, 2016 at 10:11 PM, James Drummond <jdrummond@xxxxxxxxxxx> wrote:

Tyler,

   We could organize both epics and milestones. This new feature allows multiple project boards. Testing the project feature out on a test repo the project kanban boards can be created and destroyed without effecting anything else. Maybe milestones columns we have simplified statuses like the following attached image. If an issue gets blocked or needs more information it can be moved from In-Progress back to NOT In-Progress. I am just providing these examples for discussion. One thing to note is that these boards are publicly viewable which is a good thing. Maybe we should have a Enhancement complete column so users can see both epic and enhancements separate from bugs or sub-issue part of a large epic issues. 

   This feature doesn't have any automation so each issue/PR will need to be dragged over/added manually from what I have seen.

 

 James Drummond, P.E., LEED AP BD+C | Release Manager | jdrummond@​codenvy.​com

On Sun, Sep 18, 2016 at 2:22 PM, Tyler Jewell <tyler@xxxxxxxxxxx> wrote:

Last week, GitHub introduced the concept of Projects. They are now shipping and available on our repositories.

My understanding is that they offer:

1. Kanban style boards with drag and drop.

2. A way to organize pull requests, issues, adn notes into a "work unit".

This seems like we could better organize our milestones and sprint plans using this technology.  Right now we are doing a lot of work related to creating sophisticated queries to show us the right views.

It seems that we could use projects in one of two ways:

1. Use them to visually organize an epic. 

2. Use them to visually organize the work that must be completed for a milestone.

I think the way that GitHub lets us manage epics right now is suitable. The check box style is good enough.  So I think the default here is around a milestone.

Kanban boards are organized in different columns. So we could have a project for each milestone, and then a column for each team.

Another way to manage this is that we use projects to track multi-release "projects" that span across many milestones.

Whatever we decide here:

1. We need to update some of the docs in our wiki on the development process to reflect these items.

2. We got a request to add more details around the process we use to identity pull requests ready for merge, and the selection process for issues at the beginning of a sprint.

Tyler Jewell | CEO | tyler@​codenvy.​com | 9​78​.8​84​.53​55