search

microsoft / project-oagents

Experimental AI Agents Framework
Creative Commons Attribution 4.0 International
217 stars 43 forks source link

[GitHub Dev Team Sample] Revisit Flow of working with dozens of Issues in GitHub #28

Open robinmanuelthiel opened 3 months ago

robinmanuelthiel commented 3 months ago

Is a Project Manager and Software Engineer, I find the flow of opening dozens of GitHub Issues for the single tasks of the agent very unintuitive and confusing. Especially, as it does not reflect what humans would do. In addition, I think it's weird that the agents post the code they want to generate as comments to a GitHub issue instead of opening a Pull Request, where code can be properly discussed. Lastly, closing issues before the actual work on them is done also looks like a bad practice to me.

Here is, how an ideal flow would look like to me:

  1. Human Project Manager opens a GitHub issue with a description of what to achieve
  2. Human Project Manager labels the issue with dev-agents label, to trigger the AI work
  3. First Agents starts the work and describes the project plan in Markdown as a comment to the issue
  4. Human Project Manager can give feedback and iterate on it in the comments.
  5. Once satisfied, the issue get labeled differently (e.g. coding-plan), which triggers another Agent to plan the coding work
  6. An Agent generates the step-by-step plan (To Do List) and posts it as a comment to the issue
  7. Human Project Manager can give feedback and iterate on it in the comments.
  8. Once satisfied, the issue gets labeled again (e.g. start-coding), which triggers another Agent to start the coding work
  9. An Agent creates a new branch, commits code and creates a Pull Request, with the code changes and links the PR to the issue
  10. Human Developer can give feedback on the code and iterate on it in the PR comment.
  11. Once satisfied, the PR gets merged and the Issue automatically gets closed

Am I missing anything, why the flow is not like this but happens across so many issues?

Am I misunderstanding anything, which makes my suggested flow not possible?

robinmanuelthiel commented 3 months ago

One issue I see with that is parallelism. But I still think I would massively prefer multiple Pull Requests over 30 issues...

kostapetan commented 3 months ago

I agree, we can make the flow more fluent and branch out less. The idea with PRs is interesting, as they are Issues technically, so the branching out (devs) can happen on different PRs and still don't break the implementation logic. One way would be to create a PR for a group of subtasks, for example PR for adding the frontend and PR for adding the APIs.