<div dir="ltr">There has been a good bit of dialogue in the past about the association of time windows in the Phabricator project model.  The Sprint extension requirement for start and end dates assignments to a project has been a recurring bother for many teams who would rather not associate a time window to their projects, but would like to use the Points field.<div><br></div><div>For the next Sprint extension and Phabricator update, a proposition exists to show the start and end dates on as default fields on the project creation form.  This is seen as a remedy to the confusion with these parameters being "required" for Sprint projects.  We are looking for consensus on whether this is OK.  Please chime in so that we can move forward.</div><div><br></div><div>In thinking about this a bit more, however, it occurs to me that another simple default solution exists that could also help alleviate this pain point.  This is a constantly "floating" time window.  Basically, if the dates are not set for a Sprint, the default values could be set to <i>now - 2 weeks</i> for start and <i>now + 2 weeks</i> for end.  This allows for the two primary "perspectives" for a Sprint Type project, retrospective analysis and projection.  This also essentially eliminates the need to create a new project for every Sprint, which seems to me a bit cumbersome. Nevertheless a "floating window" does not really jibe with the Agile method, which sets a fixed end date target for each development iteration.  But not all software development projects require the Agile method.</div><div><br></div><div>It is my general observation that the Sprint extension seems too limited for the variety of project management that occurs at WMF.  Clearly, a "one size fits all" solution is not the best option.  The implementation of a more abstract "Project Type" application I think would be a logical step towards greater flexibility for PM in Phabricator. Basically, a "Project Type" interface could allow teams to assign custom fields to their unique Project type definition  These Project Type to custom field associations would be static, but could be broad enough to fill more than just one need, like Agile.  Perhaps brainstorming these possibilities at the Hackathon would be useful.<br></div><div><br></div><div>For a global progress view for longer retrospection (without forecasting), for example, a new project type could be created, the "Backlog" project.  This type of project allows point assignments, and could offer new analysis reports on progress over extended periods.  Assigning a project as a "Backlog" type, could then offer a different reporting interface, etc.  <br></div><div><br></div><div>Upstream may eventually implement a similar option.  So waiting to see what they do is also an alternative. </div></div>