My overall point, Andrew, was that it might be good to consider this system Mitch is proposing as more than a "Bug Tracker for non-code issues" and use it for things such as "Trademark applications" or "submissions to JRD" or "JUG applications."
Sure, but I guess that depends on whether we are talking about an all-in-one system or whether we are talking about a review process which was what sparked by initial conversation with Brad. I don't mind which it is, but you'll just have to be more careful separating the "details" of what comment refers to which.
You are right, not all data should be open. If this system is designed as a way to enter a complaint about moderator treatment, then personally identifiable data - the description, reporter, etc., should be withheld.
But some data could still be made available in a more generic form that would provide access to general categories (ex. Moderation Complaint, TM Application) and status (open, closed, fixed, bad report), dates, etc., would help people learn about what's going on and how things are progressing.
This data can be useful to set and measure progress on goals. For example, a goal could be to reduce the number of complaints about moderation by 10%. Or, to speed processing of TM applications by 2 weeks.
I'd be reluctant to run down that road at this stage. Yes, KPI's/SLA's are wonderful things in a corporate environment (used properly), but they do not always map well to a predominantly volunteer environment where the motivation for keeping them is not directly linked to something as mercenary as a pay bonus.
On the Tracker, we can extract all of the issues for 1.5 and with it a small set of data elements and use it to show an increasing or decreasing number of problems with the router, for example, and we can demonstrate what the response rate from reporting to patch. That data is open and can be used by the community to learn about those issues and how we engage with those issues.
Yes, that's an example of what you can do on the current tracker. I don't know that there is a particularly useful direct equivalent in looking at non-code "bugs" though. At any rate, future analysis is getting ahead of ourselves.
I would never suggest people's personal lives should be open to others, whether it's a free software community, or not, nor would I equate publicity (or the availability of data) to trust. But an environment where there is useful data that is open to all is one where people are better empowered to set and measure progress towards shared goals and one in which trust is strengthened.
I'd really question whether such data should be put in public hands. I've seen some horrid conclusions being made with less sensitive data published even recently.
Could we steer back to looking at the actual process and/or the broad triggers by which a party would feel they need to use it?
Andrew Eddie - Tweet @AndrewEddie
<>< http://eddify.me http://www.kiva.org/team/joomla
- Got Joomla for free? Pay it forward and help fight poverty.