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 <piotrow...@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 王仁敏 <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 > > | > > 签名由网易邮箱大师定制 > >
