You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwhisk.apache.org by Dominic Kim <st...@gmail.com> on 2020/01/08 06:54:00 UTC

Define long/short term items for OpenWhisk

Dear whiskers.
Happy new year!

I feel OpenWhisk becomes quite mature.
And now issues are no longer straight forward and simple.
So it may take a few weeks or months to implement/fix them.

As it takes more and more time, we need standardized procedures/guidelines.
By having more guides and documents, we can enhance communication and
discoverability rather than smattering of mailing lists, video calls and
online conversations looking for answers.
I think we also need to define some long/short term items for OpenWhisk.
This is not only for just new features but for the prosperity of community
and OpenWhisk.

For example, I have felt there are some overheads for newbies to involve in
the community. It would be great to have something like:

1. Documents describing OpenWhisk internals.
More people can understand how OW works, and it would make them easily get
which components he can contribute to.
While writing documents, we might see some potential issues or improvement
points.

2. Practical guidelines for newbies to participate in contribution.
We know there are already some guides about the contribution such as
https://github.com/apache/openwhisk/blob/master/CONTRIBUTING.md and the
label "good first issue" to let them know the good items to start with. But
I saw many people are still getting hard to attend to them. We may need
more practical guidance for them. We may have a guide to setup the
development environment such as how to run the controller in Intellij.

3. A basic convention for PR(beyond the scalaFmt).
I think it is good to have rather than a mandatory item.
But if we have a basic convention, it would help people to write down codes
that are beyond the review baseline.
And it would also help reviewers as well.

The above is just one aspect of many things.
We lack a plan for future items and architectural direction.
It would be also great to have some kind of "person in charge" status.
An official procedure is also required to propose new changes,
approve/decline them, implement/maintain them and so on.
(Even if I am working on this:
https://github.com/apache/openwhisk/issues/4776)

I want to discuss the documentation tool as well.
While the markdown files in GitHub or Confluence wiki are good tools, I
feel these are not enough and developer-friendly documentation tools.
Also, many documents are scattered across many repos. Maybe we can consider
static site generators such as Hugo, Jekyll with Github pages.

There would be more items to discuss in your mind.
All these things can not be done by one or two people and I think you guys
may have a better idea about things above.

Kindly share your opinion.

Thanks
Best regards
Dominic.