How to do fast paced development that maximizes chances for success.

[wtrocki]

Hi

To clear out some of the topics over the years working in upstream we need to clarify how to work with projects like charmil.
Charmil project is:

• Starting from beginning and has no rules or required infrastructure
• We need to get results fast and reject bad ideas fast
• Moving fast and changing priorities, by adjusting issues etc.
• Giving us flexibility in the way we go and making developers sole owners of the solution (rather than being told what to do).
• Minimize hassle by not merging not approved ideas to master.

The flow that usually worked for me in such project looks like this:

1. Discuss briefly the scope of the initial POC (write proposal and research topic in issue).
   You can ping mentors for chat as well to get feedback over voice call etc.)
   DIscussus required research areas.
2. Do research in subtopics and update mentors.
3. Implement POC(s)
4. Validate POC with mentors (PR level, demo etc.)
5. Merge POC and create follow up issues.

Feel free to propose something you feel will work better.
We need some flow/expectations for anything we do that is not trivial enough (like logging or i18n)

[jjkiely]

The flow that usually worked for me in such project looks like this:

1. Discuss briefly the scope of the initial POC (write proposal and research topic in issue).
   You can ping mentors for chat as well to get feedback over voice call etc.)
   DIscussus required research areas.
2. Do research in subtopics and update mentors.
3. Implement POC(s)
4. Validate POC with mentors (PR level, demo etc.)
5. Merge POC and create follow up issues.

I like this flow, lines up pretty well with the point I made here #61 about having a central base to refer to for context when developing new features etc.
To me a clear foundation is very important as it can have a significant affect on the quality of the code created when compared to an unplanned project and also makes it easier to brainstorm improvements and new features. It helps with the documentation side of things too since you know exactly what the intended behaviour is 🙂

[wtrocki]

We started with idea of creating core/base with 2 spikes for concurrent approaches.

This failed to materialize as pocs were:

• Introducing some ideas that would not work with requirements and been overly restrictive

• Were low effort and quality that we would expect from core impl

Adjusting to that we have now in master some proven architecture pattern that we non shamesly stolen from RHOAS cli. I guess if something works for existing multi layer CLI it will work for us for the moment.

That being said once we get more features we can make second attempt at core/base. For the moment this is some lightweight and undocumented factory pattern

[wtrocki]

While comment above might sound as rant I think @ankithans really saved this project by copying factory. Without that we would most likely have failed GSOC and two unhappy students.