On this page
Su Qin: documentation, translation and writingZiggy: application distribution with openEulerLu Zhen: from code-writing to describing a taskZhang Peng: a file-transfer tool prompted by everyday workShui Ge: contribution incentives and community agreementDiscussion after the talksTurn a talk into one contributionOriginal publication: 2025-06-05. English edition and practical reading notes: Linglong editorial, 18 October 2026. Chinese original.
This retrospective was published on 5 June 2025 about the 24 May 2025 openEuler & deepin Meetup in Chengdu. The deepin and openEuler communities jointly organized it, with the Linyaps community hosting. Its theme was building an open-source ecosystem through documentation, application distribution, AI programming, tools and contribution incentives.

Su Qin: documentation, translation and writing
Su Qin, an openEuler G11N SIG maintainer, spoke about the strategic role of documentation and its connection to international participation. The retrospective reported work by G11N and doc SIGs on 162 repository READMEs, consistent directory structures and more readable operating instructions.

It also reported translation of more than 200 technical blogs and a CI Bot workflow that reduced the described translation cycle from several days to two hours. Su Qin emphasized documentation as a newcomer’s first impression and the value of standard writing patterns, including a three-step procedure template. These figures are statements in the event report, not new measurements by this edition.
Ziggy: application distribution with openEuler
Linyaps maintainer Lu Zijie (Ziggy) presented three layers: application sandbox isolation; an adapted runtime across x86, ARM and LoongArch; and operating-system integration, including openEuler. The report said he demonstrated a Linyaps application running on openEuler and discussed broader application scenarios and easier integration.

Lu Zhen: from code-writing to describing a task
Lu Zhen, a deepin system architect identified in the report as a member of the China Association of Inventions, described a collaboration model in which people define a need, AI splits it into tasks and machines generate code.

The report described a DeepSite demonstration producing an HTML5 game from natural-language instructions in one minute and a Cursor AI Agent workflow covering requirements, code generation and debugging. These were examples recounted at that event, not promises about the time needed for another software project.
Zhang Peng: a file-transfer tool prompted by everyday work
Zhang Peng explained the motivation for his open-source tool 简传: transferring files when faced with an unfamiliar computer. The design combined a local sender with a browser-based receiver using Electron-egg and Uni-app.

The report described three months from development to open sourcing, deepin integration and cross-device transfer without a tool-imposed file-size limit. Adapting it to Linyaps was a future plan in the talk, not a completed package established by the retrospective.
Shui Ge: contribution incentives and community agreement
Shui Ge, introduced as the founder of idea2app and organizer of the fCC Chengdu community, proposed a bounty/crowdsourcing model combined with GitHub Flow.

The proposal split larger needs into specified issues that developers could choose, followed by review and incentive feedback. It sought a balance between community autonomy, shared knowledge and support for less-visible needs. The report emphasized that incentive design should be grounded in community agreement.
Discussion after the talks
Participants continued discussing technical topics and contribution mechanisms. The retrospective’s closing theme was that open source includes connecting real needs, tools and people alongside writing code. It expressed an intention to continue cooperation across communities; it was not a new registration announcement.
Turn a talk into one contribution
Choose a small result another person can verify. For example, a three-step installation explanation should state its supported version, show the expected observation and explain where to report a different result.
Reader and task:
Matching source/version:
Three steps:
1.
2.
3.
Expected observation:
Known limitation:
Actual reviewer feedback:For an AI-generated tool, also review the output and test the relevant user task; a quick generation demo does not establish correctness.