You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apisix.apache.org by Zhiyuan Ju <ju...@apache.org> on 2021/12/02 12:48:57 UTC

Weekly Meeting Report (December 01, 2021)

Hi,

Yesterday, we hold an online meeting which last 90 mins, and nearly 30
developers attended. Here is the report :)

*Topic 1 - Community*

*1.* The ASF has a Community Guide here[1], here are some paragraphs I'd
like to share with you.
1.1 Everyone active in ASF projects is here as a volunteer.
1.2 Nobody in an Apache project is going to spend time teaching you
Programming 101, technical writing, or testing (to mention just a few of
the skills we need). You need to know the basics and be willing to research
the rest.
1.3 The ASF expects that everyone participating in an Apache project,
whether it be improving websites; contributing to email lists, bug
trackers, or forums hosted at apache.org; or contributing code will abide
by our code of conduct.
1.4 Let those who do the work make the decisions.
1.5 Apache projects are made up of volunteers, and we work to ensure that
all productive contributions are welcomed.
1.6 Assume that the other party agrees more than disagrees with you. We
tend to leave out agreements and focus on differences. Sometimes this is
forgotten and escalation becomes absurd for no rational reason.
1.7 If you disagree strongly with an email sent, tag it Important, then put
it aside. Read it half a day later again. Put it aside. Read it again the
next day, and then it is easier to write a balanced and inviting response,
instead of the initial vitriol that flows through us when we get upset.
1.8 Every contribution is worthwhile. Even if the ensuing discussion proves
it to be off-beam, it may jog ideas for other people.
1.9 There is nothing at the Apache Software Foundation that says you must
write code in order to be a committer. Anyone who is supportive of the
community and works in any of the CoPDoC areas is a likely candidate for
committers. - Community, Project, Documentation, Code.
*2.* One of our contributors Yilin submitted the Blog Contributing
Guide[2], welcome to read and submit your posts to Apache APISIX's
Community :)
*3.* We received feedback that, if one newcomer submits a PR, GitHub will
need the Reviewer's privilege to Approve CI Run, I need to create an ASF
JIRA ticket to check it.

*Topic 2 - Documentation*

*1.* Ingress Project would be better to include a much clear document on
how to run the E2E test locally.
*2.* Ingress Project uses HTTPS False as a default value, we’d better use
True.
*3.* In APISIX’s how to build document:
3.1 Step 1 says we need to install dependencies first, when we open that
document, it links to another page under the Other category. If this step
is necessary, maybe we could combine them into one document.
3.2 When we run commands according to the Install Dependencies document,
ETCD will be installed and executed by "nohup etcd &", this way will not
persist ETCD's data;
3.3 Also, after we install the dependencies, the OpenResty will be
installed, too. And if we try to install by using RPM directly, an error
will occur and it says we need to uninstall OpenResty, this is a little
wired. This step is removed by https://github.com/apache/apisix/pull/5659
yesterday.
3.4 After the meeting, most of the attendees agree to refactor the Install
Documentation :)
*4.* Stream Route's Documentation has something unclear, we couldn't use
this feature smoothly according to docs only.
*5.* We need to uniform Plugin Doc's structure and title, bcoz we use
`Properties` or `Parameters` in different docs.
*6.* How to migrate from Nginx to Apache APISIX?
*7.* Community users want the documentation to provide the recommended
parameter configuration for production environments, but because of the
complexity and variability of production environments, there is no fixed
parameter configuration template, so we encourage users to take the
initiative to give feedback on how best practices work.
*8.* Whether to keep the Chinese documentation? Most of us would like to
keep and keep it updated to date.
*9.* Most of the participants agreed that the documentation site is
suitable for most users, although markdown extended contents will be a
little complicated, the rendered documentation site is clearer and easier
to use. This change need another discussion IMO, we could fix the content
first :)

There have many feedbacks related to the documentation above: users would
like to use clear and correct documentation, and a variety of use
scenarios, the configuration template in the documentation, then we can
copy with slight modification to quickly use.

Thanks for your attention and feedback! I'd like to hear more from users
across mails, issues and other channels, then try to fix them and take them
back to our docs.

[1] http://community.apache.org/
[2] https://apisix.apache.org/docs/general/blog/

Best Regards!

@ Zhiyuan Ju <https://github.com/juzhiyuan>