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]
>> |
>> 签名由网易邮箱大师定制
>>
