Status: Work in Progress

Zend Framework Component Homepage System

Pitch

A Roadmap to me is "a plan of action with the aim of improving the current state" of the component. While providing timelines for specific milestones in the roadmap is beneficial, in practice it is extremely difficult to estimate and stick to completion dates especially when you don't work on it full time. If your roadmap consists of a bunch of milestones with dates you keep missing it provides limited value to users.

When I look at a Roadmap I try to establish the following:

• Is the component going in a direction I generally agree with
• Is there long-term thinking
• Can I expect a certain feature to be available in future
• Do the contributors of the component have a clear collective vision
• Is there enough organization behind the component to keep a roadmap updated

What this boils down to for me is the CUREENT STATE and the DIRECTION of the component in terms of its overall architecture and featureset. If we deem these two aspects (state & direction) as sufficient in representing a component we have several sources of information already available that can be tapped with no manual effort (issue tracker, mailing list, commit log).

I think we can develop a STATUS page for each component that will be kept updated by making the status page an integral part of the development cycle of a contributor. The component status or home page would provide a subset view into all information available about the component. This includes source code, code history, unit test results, issue tracker, documentation, examples, discussion group threads, wiki pages etc...

The component homepages can make contributors more efficient by providing a vertical interface to an ever growing set of data. It can encourage contributors to keep component homepages updated as they will be frequented by many users and will be referred to constantly from discussion group threads. There can also be a FAQ section where examples provided in discussion group threads can be cleaned-up and made available for easier access (Many contributors do such a good job explaining things to users. It is a shame that many examples get buried in the list.)

There are numerous other benefits to having Component Homepages.

Reaction

Integration with the issue tracker and CI server would keep some things up-to-date, but how would we handle things if a component’s homepage is no longer maintained? Would we archive the data and indicate that the affected sections are available for anyone who wants to maintain them? Would they have to be a significant contributor to that project?

I’m pretty used to the work patterns of our contributors. One month they are very productive WRT ZF, and the next they are on a project with a tight schedule and barely reply to emails. Very few contributors are constantly involved at a consistent level. Not that I’m complaining- it’s just a fact of OS life.

Response

If we make the component homepages a tool for contributors I am hoping that they will be used to record the current state of the project while the contributor is available to work on the component. When there is no development activity I can detect that (no commit messages, no updates to issue by contributors, no posts to mailing list containing component name). We can have an automatic development activity meter with a second manual one allowing contributors to set their current commitment (active, sporadic, temporarily unavailable, permanently unavailable, etc...). We can also have an indicator for the direction of the project (clear future direction, looking for ideas/help, etc...). When someone inquires about the state of the project on the mailing list, that thread can be shown on the homepage as a status update with a date.

We would seek contributions from as many people as possible for the homepages. There can be different permission groups for posting tutorial links, FAQ's, favorite mailing list posts (ideally with summaries), ideas, voting on items etc...