User:Jacek Antonelli/Policy Changes

Thoughts on project policies that should be changed or revised to help keep the project running well. Very loose notes so far.

ChangeLog considered harmful
Waste of effort, hard to maintain. Would be better just to put the info in the commit messages and use git log to compare versions.

Maybe keep the ChangeLog around for the benefit of non-gitters (e.g. source zip downloaders), but only update it periodically (weekly? monthly? prior to each release?), based on the git logs. We could make a script to help automate the updating.

Also, we need to revisit the ChangeLog style/format. I'm tired of Dittos.

Mailing List
Find a use for it, or scrap it. Could be useful for communication among developers.

Lighthouse
We need to define a clear and specific use for it. Open to suggestion here. Recommend using it for progress tracking, but not for bug reports or patches. Basically, a tool to aid the developers, not a user-facing thing. Analogous to LL's internal JIRA, except not hidden away.

Patches should be posted on the forums (we should make a new forum section for this) or sent to mailing list if we go that way. Regular contributors are expected to fork Imprudence on github and use the mailing list or github's pull request feature to get other developers' attention.

Help Them Help Us Help Them (Bug Reports)
We need a clear process for reporting bugs, basically a step-by-step or checklist. It should include at least:


 * 1) Fill out (or update) their system information in their forum profile. Instructions on how to do this.
 * 2) Search for similar bug reports. Instructions on how to do this. Guidelines on how to tell whether a bug is the same or just vaguely similar, and what to do if they aren't sure.
 * 3) If it has already been reported in the forums, post more info, or at least a "me too" message.
 * 4) If it is an unreported bug, create a new thread with a meaningful and descriptive subject, as much information as possible (except system info which should be in their profile instead, so they don't have to repeat it), repros if they've got em, screenshots if they'd help, etc. Clear guidelines on what info they should provide.

Encouraging and Facilitating Contributions
We need to do more of it. Specifics to be discussed.

Need to have a list of things people can work on without stepping on our toes, or us stepping on theirs.

Recruiting More Devs
We also need to do more of this. Also to be discussed.

Roadmap
We need one. Where are we going, anyway?

UI Design Guidelines
We need to sit down and come up with a coherent and consistent set of guidelines for the user interface. And then, y'know, make the UI adhere to it.

Write Out the Project Policies
We need to make it easy for people to find and read the policies, otherwise they won't know them. Duh. Wiki would be good for this. Also sticky forum threads where applicable.