As Jan said, I think “Let's plan our work in milestones based on issues and PRs” is what we need to achieve . This may not block Weex graduation, but it’s certainly worthy it.
This can separate into two questions: 1. What code will be included in next release?Is there a meeting or BDFL? 2. When will next release will be published? Is there any timetable? For the first question, I think every committer can decide what will be included next release. Whoever merges a PR, then that PR would be included in next release. On one hand, it’s a good thing that every committer has equal right, on the other hand, it reflects the weex community lacks of long term roadmap, committers may just merge PRs or write PRs without long-term visions. BTW, we do have some offline meeting of core-committers, but we only talked about big issues in these meeting, like LGPL issue in Weex or Google would ban Apps without 64bit support in August, 2019. For the second question, there is no timetable yet, but I think monthly release would benefit the contributors and users together. I’d like to make this happen unless it’s proven impractical. I think we should focus on the first issue and balance short-term work (like fixing a crash) and long-term work. The github milestone mentioned here will make our short-term work more transparency. But for long-term roadmap, I don’t think GitHub milestone will help us organize that. FYI: If you don’t mind, I’d like to suggest Renmin Wang switch to an email client with better format support. No offense. Best Regards, York Shen 申远 > 在 2019年7月4日，20:52，王仁敏 <[email protected]> 写道： > > Thank you for your detailed reply.<br/><br/>There may be some ambiguity as > previously expressed.The Reason I talk about the milestone is:<br/><br/>if > the contributors associate PR with the current milestone when they submit PR, > and also associate the ISSUE with the current milestone when is > closed.<br/><br/>the developers of the community just need to read the > milestone,and they can clear know the tasks are resolved, the ISSUE that are > solved, and the PRs that are accepted in the milestone. I think it can > improve the transparency of the Weex project.<br/><br/>After all the tasks in > the milestone are resolved, we release a new version and create a new > milestone. The contributor will continue the process in the new > milestone.<br/><br/><br/>Best Wished,<br/>Renmin Wang > At 2019-07-04 17:32:43, "Jan Piotrowski" <[email protected]> wrote: >> Thanks for bringing this up Renmin Wang. >> >> It is important to note here, that Github Milestones are just a tool >> to document and organize an organizational process. If the Apache Weex >> contributors are not actually planning in milestones, it doesn't make >> too much sense to use Github Milestones. >> >> So an earlier question how to fix the "transparency of Weex >> development is not enough" problem, is if a "Let's plan our work in >> milestones based on issues and PRs" is actually what you want. >> >> How is work currently planned? >> Are there meetings or communications where the "next issues" are >> defined and discussed? >> Is there always only one "next release" or are there multiple ones? >> Who decides what is to be worked on next? >> How is decided what goes in a release and what does not? (e.g. just >> based on what PRs there are and merged?) >> Is the planning really release focused, or maybe topic focused and >> releases are just a side effect? >> What is the planning horizon? Next release (whenever that happens), >> month, quarter, year? >> >> J >> >>> Am Do., 4. Juli 2019 um 11:20 Uhr schrieb 王仁敏 <[email protected]>: >>> >>> Hi there， >>> >>> I am very very very sorry to send so many emails with the error format >>> text. The below is the email main content: >>> >>> >>> >>> >>> As the transparency of Weex development is not enough now, even the >>> developers in the community are not sure what features are added after an >>> iteration, and when this iteration is released. >>> >>> But Github Milestone can solve this problem. >>> >>> Here are the benefits of milestones copied from reference link 1: >>> - A user-provided description of the milestone, which can include >>> information like a project overview, relevant teams, and projected due >>> dates >>> - The milestone's due date >>> - The milestone's completion percentage >>> - The number of open and closed issues and pull requests associated with >>> the milestone >>> - A list of the open and closed issues and pull requests associated with >>> the milestone >>> >>> >>> with the Milestone, developers in the community will know the progress of >>> the project easily. >>> so I propose that all PRs must be associated with Github Milestone. >>> >>> >>> BTW, The milestone check can be added to Travis CI. If the milestone is not >>> included in the PR, the Travis ci will build failed. >>> >>> >>> >>> Reference Link: >>> >>> [1]Github Milestone:https://help.github.com/en/articles/about-milestones >>> >>> >>> >>> Best Wishes, >>> Renmin Wang >>> >>> >>> | | >>> 王仁敏 >>> | >>> | >>> [email protected] >>> | >>> 签名由网易邮箱大师定制 >>> >>> >>> On 07/4/2019 16:51，王仁敏<[email protected]> wrote： >>> forget to add the reference link，sorry. >>> >>> >>> >>> >>> Reference Links: >>> 1. https://help.github.com/en/articles/about-milestones >>> >>> >>> >>> >>> | | >>> 王仁敏 >>> | >>> | >>> [email protected] >>> | >>> 签名由网易邮箱大师定制 >>> >>> >>> On 07/4/2019 16:48，王仁敏<[email protected]> wrote： >>> Hi there， >>> >>> As the transparency of Weex development is not enough now,even the >>> developers in the community are not sure what features are added after an >>> iteration, and when this iteration is released. >>> >>> But Github Milestone can solve this problem. >>> >>> Here are the benefits of milestones copyed from reference link 1: >>> >>> A user-provided description of the milestone, which can include information >>> like a project overview, relevant teams, and projected due dates >>> >>> The milestone's due date >>> >>> The milestone's completion percentage >>> >>> The number of open and closed issues and pull requests associated with the >>> milestone >>> >>> A list of the open and closed issues and pull requests associated with the >>> milestone >>> >>> I think with the Milestone, developers in the community will know the >>> progress of the project easily. >>> >>> so I proposal that that all PRs must be associated with Github Milestone. >>> >>> BTW, The milestone check can be added to Travis CI. If milestone is not >>> included in the PR, the travis ci will build failed. >>> >>> Best Wishes, >>> >>> Renmin Wang >>> >>> >>> >>> | | >>> 王仁敏 >>> | >>> | >>> [email protected] >>> | >>> 签名由网易邮箱大师定制 >>>
