Future Ice0ryx Planning & Contributions

elfenpiff commented 3 years ago

Brief feature description

Since Ice0ryx is developed by a wide variety of developers and multiple companies we need to make it transparent who is working currently on which feature. What new features are planned for implementation and how they should be implemented so that they integrate well into the overall Ice0ryx design.

Detailed information

The following aspects have to be considered.

[x] 1. How should big features like the upcoming stable API (v1.0) be planned to make the steps/issues required for the feature transparent? GitHub projects?
[x] 2. How are new features planned when some community member would like to implement them self. Suggestion:
- 2.a) Iceoryx has a documentation folder.
- 2.b) A new issue is created and discussed and leads to a pull request into the documentation folder where the issue and its possible implementation is described in detail.
- 2.c) When this pull request is merged the implementation starts.
[x] 3. Bug fixes: Suggestion: before fixing a bug an issue has to be created and has to be assigned to the one who is fixing it. If the developer cannot assign the issue a committer has to be contacted via: https://gitter.im/eclipse/iceoryx
[x] 4. Pull Requests: Suggestions
- 4.a) Are only reviewed by the committers when the CI is green.
- 4.b) The developer is responsible for their code and their pull request - no delegation.
[x] 5. Howto handle internal static code analyzer exception comments (Moved to #409)
- 5.a) The problem: If multiple companies have different static code analysis tools they maybe would like to mark exceptions via comments in the code. This can pollute the code heavily.
- 5.b) Solution property: Find a way to mark exceptions without writing them directly in the code.
[x] 6. What kind of qualifications do we expect from a contributor? Two aspects:
- 6.a) We should be open that everyone can contribute (even inexperienced C++ developers) by showing them the way to gain the knowledge. This should be realized with book suggestions, online learning material etc. not by training!
- 6.b) We need to state where you area of expertise and experience should be as a C++ developer
  - Suggestion Ice0ryx utils: well acquainted with STL, lock-free, POSIX, C++11 - C++20
  - Suggestion Ice0ryx posh: familiar with architecture and principles of iceoryx
  - Suggestion Building gateway: some C++ experience, familiar with Ice0ryx public API and gateway templates.

Outcome

When the issue is closed we should have a detailed contributer.md or similar documentation where the process is stated.

elfenpiff commented 3 years ago

@FerdinandSpitzschnueffler @dkroenke @mossmaurice @MatthiasKillat @elBoberido @budrus @dejanpan @carolinaggb

Please comment and add suggestion.

elBoberido commented 3 years ago

@elfenpiff could you number the item so that it's easier to refer to them

elBoberido commented 3 years ago

Regarding point 2. Here are some examples from other communities:

And here a short overview of the Rust RFC process

To keep everything lean I would suggest the following workflow for iceoryx:

to have a low entry barrier, keep the Issue/Bug Templates as is
before starting to work on an issue, it must be assigned to the contributor doing the work
small changes/bug fixes should be done without a design document PR
- we have to define small to prevent bikeshedding, though
for larger features, a design document PR should be created
- describe in a few words what you want to do
- if you already have a concrete implementation in mind, describe it in more detail
- if you are not sure about the best implementation
  - propose some solutions for discussion
  - write a POC and share the results in the PR
  - ask your pet
  - [something I haven't thought of]
- by the time that everybody has stopped shouting at each other, the PR can be merged
- if the implementation has started before the PR was merged, don't complain about wasted time
- the PR for the implementation also updates the design document

elBoberido commented 3 years ago

@ithier @marthtz this might also be interesting for you

dkroenke commented 3 years ago

I like the idea with the feature proposal and vote for it, thanks for the proposal! That makes development in iceoryx transparent to all who can benefit from it. For the Pull-Requests: It should be explicitly stated that the review party is open for everyone and not only for committers. We can maybe also give the hint that the developer can resolve review comments after pushing the solution for the review findings.

marthtz commented 3 years ago

Thanks for starting this discussion!

And here a short overview of the Rust RFC process

I like the idea of using an established RFC process. Maybe we need to tweak it a little bit but lets see.

4.b) The developer is responsible for their code and their pull request - no delegation.

Shouldn't we allow delegation if there's a good reason and official handover? Just in case of extended sick leave, vacation etc...

What are you guys thinking of Draft PRs? They could be used to make code visible and open a discussion on open points. Committers would then only address open points/questions in a Draft PR. Once all open points of a Draft PR have been addressed and fixed by the developer it can be set to "Ready for review" and when all checks are green code review can start. I'm just trying it out with #360

budrus commented 3 years ago

Would this be a topic for a first iceoryx developer meeting? Open for everyone interested in, announced via the gitter channel etc. and notes published somewhere here?

elfenpiff commented 3 years ago

@budrus This is a great idea! How should we organize it?

The notes can be published then on our upcoming iceoryx.io website. It is already triggered and the process is ongoing.

mossmaurice commented 3 years ago

Open points:

[x] Announce iceoryx develoer meetup on ROS discourse
[x] Add link from @ariexi

eclipse-iceoryx / iceoryx