Hi, As fa Follow-up to previous emails, I’d like to propose that new features, and major code changes affecting large portions of code and behaviors, must be documented in an Issue *before* development begins. It doesn’t have to be a book, but should outline the changes and additions, to allow for a discussion to take place. Neither does it imply that the design is rigid; often times, things change in the design as the implementation is done. But when that happens, the Issue should be updated accordingly, of course.
The issues should be used to discuss the changes, and be given sufficient time to allow feedback before development. In addition, it assures that we are not working on the same things, or things that are opposing each other. The issues do not replace documentation, but can definitely help writing documentation, as well as release notes. The issue should be assigned with an expected version Project Version. That’s the second half of this; I believe this will help us further the goal of making feature focused releases. Also, it allows the community to priotize things such that we don’t get bogged down reviewing and fixing code which is not important to an upcoming release. And of course, it helps understanding why upgrading to a particular version is important for your org and projects. And discuss. — Leif
