`Development:` Add a description of the new Artemis development process

[bgeisb]

Description

This pull request adapts the development documentation to the new development process model.

See -> https://confluence.ase.in.tum.de/display/ArTEMiS/New+Artemis+Process+Model

Open Tasks

• [x] Replace embedded template with a guide on how to use the template in Github (see @MaximilianAnzinger's comment) @bgeisb
• [x] Update documentation for the creation of a pull request. @Mtze -> This will be a follow-up PR

Preview

https://artemis-platform--8089.org.readthedocs.build/en/8089/dev/development-process/development-process.html

Summary by CodeRabbit

• Documentation
  • Updated the feature proposal template, refining problem descriptions and specifying affected users/roles.
  • Introduced a GitHub Actions workflow to automate appending the feature proposal template to issues.
  • Detailed the Artemis project's development process, including UI/UX design support and testing guidelines.
  • Added a screencast iframe for an introduction to the Artemis project.
  • Updated documentation links to reflect the new structure in the development process documentation.

[MaximilianAnzinger]

@bgeisb are you sure it's a good idea to include the template in the documentation? This means (in an ideal world) that changes in GH need to be reflected by the documentation.

[bgeisb]

@MaximilianAnzinger, great point! Instead of embedding it directly in our docs, I will guide users on how to use the template in GitHub. This way, we won't have to worry about keeping them synced all the time. Also, this PR is still a draft, so I'm totally open to more suggestions. Thanks for your input! 🙂

[github-actions[bot]]

There hasn't been any activity on this pull request recently. Therefore, this pull request has been automatically marked as stale and will be closed if no further activity occurs within seven days. Thank you for your contributions.

[bgeisb]

FYI, @MaximilianAnzinger, The embedded feature proposal template has been updated to reference the actual issue template located in the /.github directory. This change addresses your initial concern. Additionally, the process of adding the feature proposal to a feature request is now automated, as detailed in the updated documentation. :)

[coderabbitai[bot]]

Walkthrough

This update encompasses various improvements in the Artemis platform, focusing on streamlining the development process documentation and automating feature proposal management within GitHub issues. The changes aim to enhance the clarity and efficiency for contributors engaging with the platform.

Changes

Files	Change Summary
.github/workflows/.../append_feature_proposal.yml, docs/index.rst, .github/ISSUE_TEMPLATE/.../feature-proposal--developer-.md	Introduces automated appending of a detailed feature proposal template to GitHub issues, enhancing issue management and clarity. Updates link paths and refines the feature proposal template for improved specificity.
docs/dev/.../development-process.rst, docs/dev/.../screencast.html	Enhances the Artemis development process documentation with detailed guidelines and includes an embedded screencast for visual guidance.

Possibly related issues

• ls1intum/Artemis#8429: The updated feature proposal template aligns with the need expressed in this issue to automate and structure code reviews efficiently, providing clear sections for system design and requirements, supporting the implementation of the proposed GitHub action.

`

• Describe the motivation WHY the problem needs solving. Include the affected users/roles here. → Describe the motivation WHY the problem needs solving. Specify the affected users/roles.
• How should the perfect solution look like? → What would the ideal solution look like?
• System Design → System Architecture
• Outline new config options you will add. → Outline new configuration options you plan to introduce
• Potential candidates to discuss here: Websockets, Test strategy → Potential topics to discuss here include: WebSockets, testing strategies.
• UI / UX → UI/UX Design
• Screenshots of the final UI mockup → Screenshots of the final UI mockup

-->

`

• Describe the motivation WHY the problem needs solving. Include the affected users/roles here. → Describe the motivation WHY the problem needs solving. Specify the affected users/roles.
• How should the perfect solution look like? → What would the ideal solution look like?
• System Design → System Architecture
• Outline new config options you will add. → Outline new configuration options you plan to introduce
• Potential candidates to discuss here: Websockets, Test strategy → Potential topics to discuss here include: WebSockets, testing strategies.
• UI / UX → UI/UX Design
• Screenshots of the final UI mockup → Screenshots of the final UI mockup

-->

---

Recent Review Details

Configuration used: CodeRabbit UI Review profile: CHILL

Commits

Files that changed from the base of the PR and between 0183a3e6bc61c17b4e86f6aa588ab13d41605771 and 3ea5f8cd2c44baae3b7411c27c46bb1398d60df8.

Files ignored due to path filters (1)

• docs/dev/development-process/artemis-feature-proposal-flow.png is excluded by !**/*.png, !**/*.png

Files selected for processing (2)

• .github/ISSUE_TEMPLATE/feature-proposal--developer-.md (2 hunks)
• docs/dev/development-process/development-process.rst (1 hunks)

Files skipped from review as they are similar to previous changes (1)

• docs/dev/development-process/development-process.rst

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

• X
• Mastodon
• Reddit
• LinkedIn

Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai generate interesting stats about this repository and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[bgeisb]

Thanks for adding this! Generally looks very good. There are just some typos and capitalization errors which I think should be corrected. Also a couple spots where the wording could be better. I left 👍🏽 on some of CodeRabbit's reviews as well, I think you should take a look at them.

Thank you for your review, @MichaelOwenDyer. 😀 Feel free to look over it again if you like. However, I actually adopted everything as you had suggested.

[github-actions[bot]]

There hasn't been any activity on this pull request recently. Therefore, this pull request has been automatically marked as stale and will be closed if no further activity occurs within seven days. Thank you for your contributions.

[github-actions[bot]]

There hasn't been any activity on this pull request recently. Therefore, this pull request has been automatically marked as stale and will be closed if no further activity occurs within seven days. Thank you for your contributions.

[krusche]

We should definitely get more than 1 approval, please ask for other developers to approve the PR

[bgeisb]

@Hialus thank you for the detailed feedback. I suggest taking your major concerns to the developer meeting for broader discussion.

[Hialus]

Since you repeatedly state the same thing I'll just answer it here: This process was not really discussed in multiple meetings. There was one meeting over a year ago where Matthias showed the first rough draft of this idea and then there was one meeting where you apparently presented it (sadly I was not there). The process documented here does include multiple points that are not already established, hence my comments. E.g. the "a feature proposal is reviewed by the maintainers and the dev team" is currently more like "one dev discusses it with one maintainer" (with some exceptions). Another example is the part where users are supposed to state risks/challenges of a feature request. This is not in the current issue template for feature requests, so this is also not part of the established process. And the entire feature proposal workflow is only done for thesis work, not for normal feature requests by users. The workflow especially is completely new, so saying you implement an established process there is a little disingenuous.

I'd be happy to discuss this in some dev meetings, but this is going to be somewhat of a moot point if you are not participating in them. This PR is something that you have worked on over the last couple of months and it does indeed include novel parts in the dev process. Therefore, this is a discussion that you should also be party to.

[bgeisb]

Since you repeatedly state the same thing I'll just answer it here: This process was not really discussed in multiple meetings. There was one meeting over a year ago where Matthias showed the first rough draft of this idea and then there was one meeting where you apparently presented it (sadly I was not there). The process documented here does include multiple points that are not already established, hence my comments. E.g. the "a feature proposal is reviewed by the maintainers and the dev team" is currently more like "one dev discusses it with one maintainer" (with some exceptions). Another example is the part where users are supposed to state risks/challenges of a feature request. This is not in the current issue template for feature requests, so this is also not part of the established process. And the entire feature proposal workflow is only done for thesis work, not for normal feature requests by users. The workflow especially is completely new, so saying you implement an established process there is a little disingenuous.

I'd be happy to discuss this in some dev meetings, but this is going to be somewhat of a moot point if you are not participating in them. This PR is something that you have worked on over the last couple of months and it does indeed include novel parts in the dev process. Therefore, this is a discussion that you should also be party to.

@Hialus

Thank you for your candid feedback, and I apologize if my previous responses came off as dismissive. I’ve just had a clarifying conversation with @krusche, and it helped me understand that there was a significant misunderstanding on my part regarding the new development process.

I initially thought the new process was more of a directive to unify the appearance of features that was still open to refinement but meant to be tested in its current form as a first iteration. However, I now realize that this was not the case, and your concerns, especially about the workload and feasibility, are indeed valid.

Considering this, I'd like to propose a modification to the GitHub action to ensure it only triggers for issues labeled as 'large feature' or 'feature proposal.' This would create an opt-in scenario, reducing the overhead for smaller features or external contributions and aligning more with the scale of changes that require such detailed review. I believe this approach might alleviate some of the concerns you've raised.

Do you think this would be a viable solution? If so, I will adapt the action accordingly and re-request your review afterwards. Since my role primarily involved the UI/UX aspect of the new development process and my thesis is already completed, I don’t regularly attend the dev meetings. However, I am willing to join an upcoming meeting if necessary to collaboratively refine our approach.