[POC] : Clarification of the development conditions for the POC

[adebardo]

Context

This ticket aims to outline the right development practices for demcompare merge to xdem, inspired by CS-CNES. The goal here is to have the methods validated by xDEM developers. The rules will be listed, and it will be necessary to either check the box to validate or open a thread in this ticket.

• The conclusions will be copied to a page in the wiki.

Development

Keywords

• sprint: development duration (1 month here)
• sprint planning: meeting to choose tickets to be developed in a sprint
• retrospective: feedback meeting

Implementation

• Create a milestone per month for the study (will see in september)
• Create a poc branch : frequency of merging ?
• Create a story listing the tickets required for the POC development (WIKI) : can change if an efficient way of maintaining the story is found
• backlog : The backlog is made of issues already validated and estimated (days) to be taken in a sprint

An issue's life

All label can be named with the prefix "[POC]" (example: label "conception TODO" --> label "[POC] conception TODO"

• Ticket created with context details --> label "conception TODO"
• Refinement: ticket study and development proposal (Review + validation by project maintainers ) --> label "conception to review"
  • context
  • tests to be implemented
  • development assistance
  • number of days needed
• issues already validated and estimated (days) to be taken in a sprint --> label "backlog"
• The ticket enters the sprint during a sprint planning --> label "TODO"
• The ticket is under development --> label "DOING"
• The ticket is internally reviewed by project developers --> label "to review" (TO BE COMPLETED)
  • pre-commit ok
  • CI ok
  • Push Request: detailed
• The ticket is completed --> label "DONE"
• Ticket reviewed and validated by CNES and Glaciohack TEAM--> merge (into the poc branch)
• If the ticket cannot be implemented ---> label "STUCK"

Meetings

• Communication via Slack
• Storage in the Grenoble University space
• Calls via Zoom
• CS: implementation of daily stand-ups
• CS + CNES (+ glaciohack): implementation of weekly meetings
• CS + CNES + glaciohack: sprint planning and retrospective once a month

Development Environment

• From a Linux environment with venv ? mamba ? (TO BE COMPLETED)

[adebardo]

@adehecq we can talk about it whenever you want

[adehecq]

If I understand correctly, we will need to create several labels like “conception TODO”, “conception DONE”, “backlog”, "TODO", "Doing" etc? If so, I would indeed use the prefix [POC] or other for clarity.
Otherwise, this way of functioning sounds good to me.

[adebardo]

@duboise-cnes its seems okay for you ?

[duboise-cnes]

Thanks @adebardo for the issue.

For the title, i would have put that the ticket aims to find the right development conditions for demcompare merge to xdem, inspired by CS-CNES not "This ticket aims to outline the development practices implemented for the 3D tools maintained by CS Group for CNES. The goal here is to have the methods validated by xDEM developers"... juste to be sure that the goal is not to reproduce exactly what we do for 3D projects but just be inspired.

So if @adehecq is ok with the processus globally, it is fine for me too. Ok for [POC] before to separate from current labels easily. Some comments nevertheless:

• don't forget the number of days needed to do the tasks in conception-doing
• I would put " Review + validation by CNES " in conception - done and not only by CNES but by project maintainers (linked with governance). So for now me and glaciohack. We will have to be sure with governance discussion.
• The backlog is made of issues already validated and estimated (days) to be taken in a sprint
• for the label to review: maybe we can enlarge the reviewing to all developers (CS, CNES, glaciohack). Maybe not during study. Depends if you are two or one developper in the project ;)
• Ok for the end in label "Done" with a generalisation to project maintainers (linked with governance of the project). For now, ok with CNES/Glaciohack
• we may need Stuck phase if needed during the dev

And we will adapt after if we have other needs through retro and evolution of the process to fit all members needs.

Implementation part:

• Create a milestone per month for the study: are you ok for one month or at too long for the beginning ? To adapt after vacations...
• Create a poc branch : frequency of merging ? --> do you mean frequency of rebase from main xdem branch ? maybe to be answered by amaury and romain depending on major updates in xdem main branch. Ok for poc name if explicit enough.
• Create a story listing the tickets required for the POC development (WIKI) --> this must be easy to update to have a "roadmap" macro view of developpement of all stories and issues. So maybe more an EPIC in agile terminology... but i think more clear to only say Development roadmap with a shared and easy view of the POC dev.

For meetings: ok.

• maybe store in the github wiki and no more on shared Grenoble university space to keep all in github public repo at one place now ?
• ok for weekly meetings
• ok for sprint and retro (maybe adapt the format to fit CNES/Glaciohack view)

Dev environment:

• for dev I would aim for only classic venv and pip install and keep only mamba (conda like) for end users ease. @adehecq ok ?

Here my returns ;)
Manu

[adebardo]

For the frequency of merging :

• i think a rebase each time a commit is added to main branch avoid problems
• i was talking about do we merge the poc branch once, or every sprint, or every 10 commits ...

I don't think everything needs to be on github but i still need a place to share them

[rhugonnet]

All good for me too regarding this way of functioning.

For the frequency of merging with main: I would say whatever is the most efficient for you in terms of dev to avoid branching too many times from other branches.

We currently have a fairly flexible organization for merging in main. We basically merge every change that is stand-alone immediately and, once some of them have built up to a distinct functionality and that this functionality is properly documented, we make the functions public and publish a new release to introduce/improve that functionality. In the event that some bits of a functionality are started in main but not finalized to the point where we want to make a release out of them, but we still needed to publish a release for another functionality (or bug fix), we'd either make these functions non-public in the meantime (like _myfunc) or simply not document them in the API reference/doc until a later release. So that main can contain a bit of "future" code that is tested, but not yet grouped into a new functionality ready to be released with documentation.
Do you think this organization would still make sense?

[adebardo]

I don't think that is a problem, we can add that to the ticket.
Also, it's good that we're not imposing our development approach.
@duboise-cnes, you aggreed ?