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 王仁敏 <hnht...@163.com>: > > 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 > > > | | > 王仁敏 > | > | > hnht...@163.com > | > 签名由网易邮箱大师定制 > > > On 07/4/2019 16:51，王仁敏<hnht...@163.com> wrote： > forget to add the reference link，sorry. > > > > > Reference Links: > 1. https://help.github.com/en/articles/about-milestones > > > > > | | > 王仁敏 > | > | > hnht...@163.com > | > 签名由网易邮箱大师定制 > > > On 07/4/2019 16:48，王仁敏<hnht...@163.com> 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 > > > > | | > 王仁敏 > | > | > hnht...@163.com > | > 签名由网易邮箱大师定制 >
