You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@weex.apache.org by 王仁敏 <hn...@163.com> on 2019/07/04 08:48:46 UTC
[DISCUSS] Add Github MileStone When PR
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
| |
王仁敏
|
|
hnhtwrm@163.com
|
签名由网易邮箱大师定制
Re: [DISCUSS] Add Github MileStone When PR
Posted by Jan Piotrowski <pi...@gmail.com>.
Just to bring up an idea of a still lightweight, still Github based,
but already a bit more formal planning process:
Import all issues and PRs into a GitHub project boards, then decide
which ones are just "support/questions" (column) vs. work items.
Former are irrelevant here, latter go into a "backlog" (column). The
backlog then is prioritized, sorted, filtered to get to the "next"
(column) items (probably in some kind of meeting or discussion process
- this can be quite hard in a distributed work situation so maybe this
can be delegated to a few trusted parties of the community). The end
result then can be the basis for formal milestones that are used by
developers to select their work.
Of course this can get a _lot_ more fancy and process based - but with
cost of additional effort.
J
Am Do., 4. Juli 2019 um 11:32 Uhr schrieb Jan Piotrowski <pi...@gmail.com>:
>
> 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 王仁敏 <hn...@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
> >
> >
> > | |
> > 王仁敏
> > |
> > |
> > hnhtwrm@163.com
> > |
> > 签名由网易邮箱大师定制
> >
> >
> > On 07/4/2019 16:51，王仁敏<hn...@163.com> wrote：
> > forget to add the reference link，sorry.
> >
> >
> >
> >
> > Reference Links:
> > 1. https://help.github.com/en/articles/about-milestones
> >
> >
> >
> >
> > | |
> > 王仁敏
> > |
> > |
> > hnhtwrm@163.com
> > |
> > 签名由网易邮箱大师定制
> >
> >
> > On 07/4/2019 16:48，王仁敏<hn...@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
> >
> >
> >
> > | |
> > 王仁敏
> > |
> > |
> > hnhtwrm@163.com
> > |
> > 签名由网易邮箱大师定制
> >
Re: [DISCUSS] Add Github MileStone When PR
Posted by 申远 <sh...@gmail.com>.
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，王仁敏 <hn...@163.com> 写道：
>
> 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" <pi...@gmail.com> 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 王仁敏 <hn...@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
>>>
>>>
>>> | |
>>> 王仁敏
>>> |
>>> |
>>> hnhtwrm@163.com
>>> |
>>> 签名由网易邮箱大师定制
>>>
>>>
>>> On 07/4/2019 16:51，王仁敏<hn...@163.com> wrote：
>>> forget to add the reference link，sorry.
>>>
>>>
>>>
>>>
>>> Reference Links:
>>> 1. https://help.github.com/en/articles/about-milestones
>>>
>>>
>>>
>>>
>>> | |
>>> 王仁敏
>>> |
>>> |
>>> hnhtwrm@163.com
>>> |
>>> 签名由网易邮箱大师定制
>>>
>>>
>>> On 07/4/2019 16:48，王仁敏<hn...@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
>>>
>>>
>>>
>>> | |
>>> 王仁敏
>>> |
>>> |
>>> hnhtwrm@163.com
>>> |
>>> 签名由网易邮箱大师定制
>>>
Re:Re: [DISCUSS] Add Github MileStone When PR
Posted by 王仁敏 <hn...@163.com>.
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" <pi...@gmail.com> 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 王仁敏 <hn...@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
>>
>>
>> | |
>> 王仁敏
>> |
>> |
>> hnhtwrm@163.com
>> |
>> 签名由网易邮箱大师定制
>>
>>
>> On 07/4/2019 16:51，王仁敏<hn...@163.com> wrote：
>> forget to add the reference link，sorry.
>>
>>
>>
>>
>> Reference Links:
>> 1. https://help.github.com/en/articles/about-milestones
>>
>>
>>
>>
>> | |
>> 王仁敏
>> |
>> |
>> hnhtwrm@163.com
>> |
>> 签名由网易邮箱大师定制
>>
>>
>> On 07/4/2019 16:48，王仁敏<hn...@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
>>
>>
>>
>> | |
>> 王仁敏
>> |
>> |
>> hnhtwrm@163.com
>> |
>> 签名由网易邮箱大师定制
>>
Re: [DISCUSS] Add Github MileStone When PR
Posted by Jan Piotrowski <pi...@gmail.com>.
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 王仁敏 <hn...@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
>
>
> | |
> 王仁敏
> |
> |
> hnhtwrm@163.com
> |
> 签名由网易邮箱大师定制
>
>
> On 07/4/2019 16:51，王仁敏<hn...@163.com> wrote：
> forget to add the reference link，sorry.
>
>
>
>
> Reference Links:
> 1. https://help.github.com/en/articles/about-milestones
>
>
>
>
> | |
> 王仁敏
> |
> |
> hnhtwrm@163.com
> |
> 签名由网易邮箱大师定制
>
>
> On 07/4/2019 16:48，王仁敏<hn...@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
>
>
>
> | |
> 王仁敏
> |
> |
> hnhtwrm@163.com
> |
> 签名由网易邮箱大师定制
>
Re:[DISCUSS] Add Github MileStone When PR
Posted by 王仁敏 <hn...@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
| |
王仁敏
|
|
hnhtwrm@163.com
|
签名由网易邮箱大师定制
On 07/4/2019 16:51，王仁敏<hn...@163.com> wrote：
forget to add the reference link，sorry.
Reference Links:
1. https://help.github.com/en/articles/about-milestones
| |
王仁敏
|
|
hnhtwrm@163.com
|
签名由网易邮箱大师定制
On 07/4/2019 16:48，王仁敏<hn...@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
| |
王仁敏
|
|
hnhtwrm@163.com
|
签名由网易邮箱大师定制
Re:Re:[DISCUSS] Add Github MileStone When PR
Posted by 王仁敏 <hn...@163.com>.
Hi there，<br/><br/>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.<br/><br/>But Github Milestone can solve this problem.<br/><br/>Here are the benefits of milestones copied from reference link 1:<br/>- A user-provided description of the milestone, which can include information like a project overview, relevant teams, and projected due dates<br/>- The milestone's due date<br/>- The milestone's completion percentage<br/>- The number of open and closed issues and pull requests associated with the milestone<br/>- A list of the open and closed issues and pull requests associated with the milestone<br/><br/>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.<br/><br/>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.<br/><br/>Reference Links:<br/>1. https://help.github.com/en/articles/about-milestones<br/><br/><br/>It seems that some of the formatting of my mail text disappeared，maybe because my Mac OS version is 15.03 beta.sorry!<br/><br/>Best Wishes,<br/>Renmin Wang
在 2019-07-04 16:51:23，"王仁敏" <hn...@163.com> 写道：
>forget to add the reference link，sorry.
>
>
>
>
>Reference Links:
>1. https://help.github.com/en/articles/about-milestones
>
>
>
>
>| |
>王仁敏
>|
>|
>hnhtwrm@163.com
>|
>签名由网易邮箱大师定制
>
>
>On 07/4/2019 16:48，王仁敏<hn...@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
>
>
>
>| |
>王仁敏
>|
>|
>hnhtwrm@163.com
>|
>签名由网易邮箱大师定制
>
Re:[DISCUSS] Add Github MileStone When PR
Posted by 王仁敏 <hn...@163.com>.
forget to add the reference link，sorry.
Reference Links:
1. https://help.github.com/en/articles/about-milestones
| |
王仁敏
|
|
hnhtwrm@163.com
|
签名由网易邮箱大师定制
On 07/4/2019 16:48，王仁敏<hn...@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
| |
王仁敏
|
|
hnhtwrm@163.com
|
签名由网易邮箱大师定制