你好

第84节 OpenIM standardization


❤️💕💕记录sealosopen in new window开源项目的学习过程。k8s,docker和云原生的学习open in new window。Myblog:http://nsddd.topopen in new window

[TOC]

document-driven

🔥 Questions THAT can BE SOLVED WITH DOCUMENTATION and SEARCH, DON'T ASK !!!

  • Github Issue
  • Google Doc
  • Pull Request

Automation and Simplification

Once the code is submitted, it is automatically put online

  • util test
  • gray-box testing
  • auto build & push images
  • auto code link
  • make

OpenIM Owner Culture

Owner culture requires that everything should be defined as an Owner, and this Owner has the right to give orders to other people, and other people have the obligation to cooperate with him.

A large RFC proposal can have many features:

RFC✨: OpenIM Test Auto @Xinwei Xiong (cubxxw)

  • [x] util test @Xinwei Xiong (cubxxw)
  • [x] ete test @hrxiang491064739@gmail.com
  • [ ] etc …

So for the issue:

  • example: https://github.com/OpenIMSDK/Open-IM-Server/issues/385

Review Culture *

For each PR, the conditions must be met, otherwise the review is forbidden to pass:

  1. The code is logically correct.
  2. Connect one or more issues
  3. The actions test all pass
  4. extrusion type and auto merging
  5. It must be signed (1 to many)

Collaborative tool *

I tend to give people access to the most advanced tools, so that everyone in our team's tastes are imbued with these good tools.

  • **Github ***
  • **********Slack ***********
  • Zoom

Work communication. Mainly use Slack, Slack as an information distribution center, can be divided into channels, can be divided thread discussion, wechat note is a slag.

Slack invite: https://join.slack.com/t/openimsdk/shared_invite/zt-1tmoj26uf-_FDy3dowVHBiGvLk9e5Xkg

Goal and commitment (1 & 0)

Every one of us is a leader, manage each of your tasks. It's great, but,

We need to be visible

  • at least one issue a day
  • Summarize issues at least once a day (Comment OR PR)

Release agreement *

The main repository does not allow the creation of any branches. (main, release-v*, dev etc

All branches of a personal repository must be named according to the specification

  • example:

自己的工作流总结，githook 设计和配置，以及 Makefile githook 支持open in new window

Distribution agreement *

  • release branch and main branch
  • Optionally merge the main branch into release-v* branch based on milestone and bugs

tag strategy:

语义化版本 2.0.0open in new window

Biweekly meeting *

  • OpenKF weekly meeting: Maintain and develop the project, developers discuss and learn.
  • OpenIM Biweekly meeting: In the form of live broadcast + conference discussion, we will answer questions from users and community contributors.

Representative-OpenKF

https://github.com/OpenIMSDK/OpenKF

🔥 Specification of OpenIM from the OpenKF perspective， @Bo IRONIC

An ordinary contributor to OpenIM: @Bo IRONIC

  1. Docs: raise an appropriate object in an issue, etc…
  2. Issue: but what else do I need to do when I finish the documentation, labels, Milestone, select Developmen, etc…
  3. User Tools: local use make tools test, build and run, etc…
  4. PR: how do I present a quality and qualified PR.
  5. Review: how do you review someone else's code

END

  • Ownership & Leadership
  • Initiative
  • Objectives Oriented (Project managers and product managers)
  • Insists on High Standard
  • https://github.com/lukasz-madon/awesome-remote-job
  • https://github.com/OpenIMSDK/Open-IM-Server/blob/main/CONTRIBUTING.md

END 链接