Organization: add PROCESS.md and ROADMAP.md

[laurentsenta]

• Who should review and be part of the discussion?
• Add content from https://github.com/libp2p/interop/
• Make the tables readable in text view
• Drop authors and reviewers section, that's handled by git(hub)

[BigLep]

Thanks for starting this @laurentsenta . A few things:

1. What do we think it will take to merge this? Basically, when are you considering it done? Are you wanting to see all of these questions answered? Just some of them?
2. An important part of this experience is when a test fails, is it pretty straightforward for someone to see who the culprit is? For the "big test", does someone get a dump of all the combinations that were run and which ones passed/fail so they can identify the failure source (see notes on that below)?
3. I like the idea of having a dashboard that shows that, for example, the "Simple PING" "big test" here was the last run, here were all the implementations/versions that were run, and here was the result state (pass or fail) and execution time.
4. Lets answer what happens in the "big tests". For example, if I have these libp2p nodes go-vA.0, go-vB.0, rust-vC.0, rust-vD.0, is there a pairwise set of asserts that are run like, something like this:

   go-vA.0 / go-vB.0
   go-vA.0 / rust-vC.0
   go-vA.0 / rust-vD.0
   go-vB.0 / rust-vC.0
   go-vB.0 / rust-vD.0
   rust-vC.0 / rust-vD.0

?

Basically, what I'm wondering in a "big test" whether we'll be able to see which combinations ran, did they success, how long they took, etc.
Also, ideally that does run on a cron job and someone can come to libp2p/test-plans and click into the latest results.

[laurentsenta]

@BigLep

1. What do we think it will take to merge this? Basically, when are you considering it done? Are you wanting to see all of these questions answered? Just some of them?

• Ideally I'd like to import info about the libp2p/interop repository to mark this as ready for review,
• Then have the rest of the team review & share input,
• To me, every question below When do we revisit this scenario to improve and gather feedback? needs an answer. We probably don't have enough information to answer the other questions.

2. An important part of this experience is when a test fails, is it pretty straightforward for someone to see who the culprit is? For the "big test", does someone get a dump of all the combinations that were run and which ones passed/fail so they can identify the failure source (see notes on that below)?
3. I like the idea of having a dashboard that shows that, for example, the "Simple PING" "big test" here was the last run, here were all the implementations/versions that were run, and here was the result state (pass or fail) and execution time.
4. Lets answer what happens in the "big tests". For example, if I have these libp2p nodes go-vA.0, go-vB.0, rust-vC.0, rust-vD.0, is there a pairwise set of asserts that are run like, something like this:

   go-vA.0 / go-vB.0
   go-vA.0 / rust-vC.0
   go-vA.0 / rust-vD.0
   go-vB.0 / rust-vC.0
   go-vB.0 / rust-vD.0
   rust-vC.0 / rust-vD.0

?

Basically, what I'm wondering in a "big test" whether we'll be able to see which combinations ran, did they success, how long they took, etc. Also, ideally that does run on a cron job and someone can come to libp2p/test-plans and click into the latest results.

• We worked the other way around: implementations run tests to prevent merging "broken" code, they have to run quickly enough and signal that something is broken at best (not much more feedback).
• That approach makes a lot of sense and can be done easily for libp2p days 👍

[galargh]

1:1 notes:

• this (edit: the dashboard setup) is a high-priority task for libp2p day
• I (@galargh) can help out with this task to free up @laurentsenta (as he will have other tasks that have to be completed for libp2p day)
• we're going to meet up to discuss specific action items

[BigLep]

Thanks for starting this @laurentsenta and adding the ROADMAP. I think you're first "short term" milestone is a great place to get libp2p/test-plans and let libp2p to take over from there.

If there is contention on the DESIGN.md file, I think it would also work for it to be in its own PR.

[BigLep]

Will we also give insight into which versions are being run?

[BigLep]

Great - thanks!

[BigLep]

Combine with your other "Questions" section below?

[mxinden]

Thank you @laurentsenta for writing this up. I am sorry I haven't taken a look earlier.

[mxinden]

Note, in case these items are ordered by priority:

In my eyes, for the libp2p team, covering essential features (item 2) is more important than a page to discover the results (item 1). In other words, I think we should first create the things before figuring out a way to display them.

[p-shahi]

Marking this as ready to review with the aim of merging it today. It has gone through review in #56 as well as earlier here.

The next steps before merging are:

• address open comments

• add links to GitHub issues

The immediate projects have been assigned completion targets but some are missing them. These will be addressed in a followup as they need more investigation.