Discussion: Joomla and non-code "bugs"

[Robert_Vining]

The first beta task might be to track the progress on what all is currently being done within the Joomla teams to communicate better with the community.

#justsayin

[Toni Marie]

Regular readers of various sites and threads within Joomla will know we said "we have something in the works" for quite some time.

I personally have not wanted to put pressure on the third party dev team nor the Joomla devs--all volunteering time on this--before it was ready.

It seems though that more detail was needed to prevent more speculation and wasted work. The CRM (JForce) is publicly available and was not built from the ground up for us. It's the only GPL full solution for our needs. The JForce team has sure as heck added a whole bunch of features and changes for us though. I'm pretty sure several of the improvements were rolled back into the code.

[brian]

I guess the TM usage rules dont apply to them then. Now that would be an ideal second post in the "mayday".

#justsayin

[AmyStephen]

Toni Marie - that's VERY helpful, thank you! I need to look back at Andrew's initial post and see if maybe he was introducing this new system? Or, talking more specifically about an Ombudsman type process that might build on this? I'm not sure where we got confused.

I understand Brian's comment, too, about improving communication (is there anyone in the project whose eyes don't roll hearing that phrase anymore? lol) Toni Marie is right, though, there has been a lot of communication about improving the system, just not specifics, and perhaps because we weren't all aware of this bigger effort, we eagerly jumped into solving some problems that are well on their way to being solved. Then, seeing that it's been underway for 8 months, feels a little frustrating.

HAVING SAID THAT, who cares? Let's embrace what makes us better and what Toni Marie has explained (and to which Elin referred) sounds very good.

I am really glad to see the Joomla! Community Magazine "working in the open." Let's all watch and see if that model of teams pulls in more contributors. Or, ends up creating too much work to manage. If that's a successful experiment, moving towards that structure, as much as possible, certainly could help with the communication.

Toni Marie - thank you for that very clear explanation. It sounds like you guys are doing great work. I will certainly be looking at JForce as soon as I am able.

[AmyStephen]

I guess the TM usage rules dont apply to them then. Now that would be an ideal second post in the "mayday".

#justsayin

Was looking at the site and then Brian's comment finally made sense.

Shouldn't Extreme Joomla! have the trademark permissions statements on their site? Especially since they are commercial? I understood that was requisite to being listed there?

[Toni Marie]

This happens all the time when people do redesigns of their sites. They did a redesign this summer, and while they were working overtime to complete some rough demo stuff so we could approve this choice of solution.

We encounter the missing trademark info after redesigns all the time, a quick note and it's always restored. We also don't call out everyone who ever made that mistake and name them publicly. I'm a little sad at the naming of names, but I'm also feeling a little guilty that I hadn't warned the Jforce folks to be prepared for such scrutiny.

[Toni Marie]

In retrospect, this is actually a great example of how our new CRM will handle problems in the future. With a documented record of when the trademark statement was on the site, we could with absolute certainty say whether it was an oversight at redesign or a part of the approval process that slipped through the cracks. We'd then have the timestamped request note in the system and a way to confirm they'd responded. And everyone from the JED team to the Connect team would be able to view the whole process and be able to answer with as much certainty as I had (since we on the JED team approved the listing).

The checklist for approvals is one of the first modifications we requested to the layout/workflow of the system.

Also as a side note, all GPL products prior to the cutoff date were not viewed with the same trademark scrutiny. When would we in the JED get time to look at 3000 listings to make sure every website had the trademark info? We handle that by report, not proactively. If you find a site that lacks the trademark statement, please feel free to report it in the JED. The new system will have an even better tracking but that's a good start.

[AmyStephen]

Nah, this isn't shameful! Shameful is suddenly realizing you went to work without putting any clothes on! This is just something we do.

Toni Marie - you got a good handle on things. That sounds like a perfect example of how this system will help fill in gaps of information.

Thanks for taking care of reminding them!
Amy

[brian]

I'm really confused now about this whole thread

IT seemed to start with this

There's a fantastic discussion over on the Joomla Community Workgroup Leadership List(TM) that includes a carefully crafted email from Andrew Eddie (forwarded by Brad Baker) about creating a place for folks to call out for help, expose problems, raise concerns/complaints etc.

and went on to talk about being a tracker for the entire joomla project

IF this jforce customisation has been underway for 8 months now why isnt that being used and then the project has a single point of call for all non code items

[masterchief]

I think an ombudsman at minimum would send a message to the community that ultimately there is somebody who may agree or disagree but will definitely listen, try to help and be reasonable and constructive. Perhaps in this way an ombudsman could also help restoring trust within the community if and where that is lacking.

That sort of ethereal idea (assisted by improvements in technology for sure) is what I had in mind, yes. I guess in a sense I've actually performed that role on many occasions for people. I take complaints very seriously and investigate them to the best of my ability. The majority of cases are people just not understanding what's going on and a short conversation usually clears up the confusion. Complaints against individuals are less frequent and generally "complicated" because you are dealing with two people are their relative perspectives of the same situation. Usually that results in "well, you are both right and wrong and need to take a step back" (in extreme cases though, the only way forward has been formal mediation). The most rare are where I've "judged" something and the complainant hasn't wanted to accept it (I cited the case I had the other day) and at the other end of the spectrum I've had a small number of cases of stories that turned out to be, in my opinion, manufactured for malicious intent (one serious case at the time of the Mambo fork).

Would be interesting to actually get a hold of a real ombudsman and chat to them about how they handle such things.

Edit: fixups

[AmyStephen]

Here's a good best practices piece from the International Ombudsman's Association (Universities typically belong to this association): http://www.ombudsassociation.org/standa ... 101309.pdf

It is really important that an ombudsman not hold any other position in an organization. They would have to have full access to the data we are talking about in this thread. They should be trusted, not only to listen, but also to investigate the facts of the reports, and to advise the reporter as to their best course of action within the organization. Both the project and the community would have to believe that those in this role (could be a team) would be fair and impartial.

I don't know if it would be good, or not, for Joomla! to have an Ombudsman. It depends on whether or not the project feels this approach could help the project advance more quickly and it also depends on whether or not the project is open to adapting to suggestions the Ombudsman might propose.

[masterchief]

I don't know if it would be good, or not, for Joomla! to have an Ombudsman. It depends on whether or not the project feels this approach could help the project advance more quickly and it also depends on whether or not the project is open to adapting to suggestions the Ombudsman might propose.

Well, like I said, that was "sort of" the idea. We could certainly create our own equivalent flavour of the role. Probably no equivalent in the Open Source universe at present and we'd be the ice breaker yet again Though, just thinking out loud, if you want it to be really impartial, maybe there is an organisation that does that in the same way the SFLC does our licensing support. Regardless, though, that is the last resort and there would still need to be a complaints division here to triage and deal with the easily fixed stuff (that's the part the system that helps prevent the pot boiling over in the first place). In the real world you can't go to the ombudsman without talking to the "company" about the problem first.

Note, that will need to be assisted by technology and if it helps you (royal you) articulate your thoughts, then by all means use your favourite application (Redmine, whatever) as an example. However, the point is digging into the process of how you would use it to solve a problem, not necessarily what features it has.

To that end, maybe it's helpful to start shaping the list of things we should be expected to deal with. From what I've heard they fall into the following camps (and let's please consider people innocent until proven otherwise):

* Excessive time to execute some approval process (JED or JRD or Showcase listing, JUG, domain name, patches, etc).
* Dispute a decision of some approval process (refused listing or name approval, patch refused, etc).
* Complaint about forum moderation (too soft, too hard, etc).
* Security issue inappropriately handled.

Is there any other general issue that doesn't fall into those broad categories?

[brian]

I would guess these two might be different categories

• handling/rejecting of code ideas

• handling/rejecting of volunteering service/help

[Toni Marie]

Andrew's listing of the basic current complaints/concerns was the reason we chose to get a little more detailed about our communication improvements.

It's not that we mean for the software to fill the "ombudsman" role, but rather that we feel many of the communication complaints will be solved with this system. Really 2/3 of his list is being handled by that system.

All of our efforts to improve communications and to respond to complaints really needed to be expressed as part of this discussion.

[masterchief]

I would guess these two might be different categories

• handling/rejecting of code ideas

• handling/rejecting of volunteering service/help

Yeah, I had wondered about those to but I felt they fell into a grey area.

Certainly in terms of the first one, to coin a phrase from you "just speak up" on the Dev list. I sort of covered the area of patches not being dealt with but with development if you aren't bringing issues up on the lists, then the problem is probably not going to be addressed. As I said in my original script, I think developers are used to discussing ideas and shooting holes in them without (generally) people taking offense. 1.6 is certainly made up of a far bigger idea pool than any previous version ever so I would hope this category would be seldom, if ever, used.

The second one is more challenging to solve because there are a lot of factors involved. But granted, it could be a source of friction if handled improperly.

[masterchief]

It's not that we mean for the software to fill the "ombudsman" role, but rather that we feel many of the communication complaints will be solved with this system. Really 2/3 of his list is being handled by that system.

Yes. I actually think that we'll nuke most of the problems just by organising the processes better. This is not a bad thing. The lack of problems would suggest something far worse

[AmyStephen]

Andrew and Brian's items are good. I'd include Brian's, Andrew, even though it can be "tough to evaluate." Might as well allow pretty much any issue to be reported, rather than second guess what might be brought forward.

Another item that sometimes gets a bit of attention is when someone reports an Extension (for not being GPL, or the Web site not being GPL, or TM issues, or Security problems), and it isn't unpublished within a few weeks (or not ever unpublished).

Also, since the Magazine is returning we should get ready for a whole new set of issues!

[masterchief]

Another item that sometimes gets a bit of attention is when someone reports an Extension (for not being GPL, or the Web site not being GPL, or TM issues, or Security problems), and it isn't unpublished within a few weeks (or not ever unpublished).

That's actually a slightly different issue because I assume you, as the submitter, are actually a third-party to the process. You may not be party to the decision/negotiating/resolution process. If you don't get any response, then I think that's in, but if you've been notified "thanks, we'll handle it", that's where your involvement stops. At least, that would be my take on it.

[AmyStephen]

It would be nice if it were that simple, Andrew, but some of the drama comes from people feeling like there is unfair treatment and that there is no way to raise that issue. I think it's probably important.

Maybe "Lack of follow through for reported problem" or "Possible Privileged Treatment?" Anyway, just thinking on some of what I hear "out on the streets."

Thanks!

[masterchief]

Maybe "Lack of follow through for reported problem" or "Possible Privileged Treatment?" Anyway, just thinking on some of what I hear "out on the streets."

Those two are quite different. Cronyism is a fairly serious allegation and would need to be handled very carefully - it could be (actually has been) easily abused.

[brian]

I would guess these two might be different categories

• handling/rejecting of code ideas

• handling/rejecting of volunteering service/help

Yeah, I had wondered about those to but I felt they fell into a grey area.

Maybe but better to include them at the start and see if they get uses?

Certainly in terms of the first one, to coin a phrase from you "just speak up" on the Dev list. I sort of covered the area of patches not being dealt with but with development if you aren't bringing issues up on the lists, then the problem is probably not going to be addressed. As I said in my original script, I think developers are used to discussing ideas and shooting holes in them without (generally) people taking offense. 1.6 is certainly made up of a far bigger idea pool than any previous version ever so I would hope this category would be seldom, if ever, used.

I think I meant they way ideas are "shot down" not that they are rejected. Not everyone is confident enough in themselves to fight a corner in public, if they are dismissed quickly,

[masterchief]

Maybe but better to include them at the start and see if they get uses?

Sure.

I think I meant they way ideas are "shot down" not that they are rejected. Not everyone is confident enough in themselves to fight a corner in public, if they are dismissed quickly,

Ok, but anyone could "shoot them down" per se. I think you can treat the dev lists just like the forum. If there is a problem with how a situation is handled by the leadership (basically involving a breach of the code of conduct), there's ground for a complaint.

[AmyStephen]

Backing up a minute, though...we aren't trying to find problems with the project, or the project leadership, or a working group, or a team on a working group, or with anyone specific within the project. We simply want to recognize frustration early so that an appropriate and helpful response can be made to better serve the community.

Brian is pointing to a common frustration. It's entirely possible a number of developers might report the process for "presenting their *super awesome* ideas" to be flawed. They might claim a lack of response, or argumentative response, or immediate dismissal of their ideas and the ideas of others, as the issue, and be able to back up their claims with links and testimony and twenty seven eight-by-ten color glossy photographs with circles and arrows and a paragraph on the back of each one.

In this case, the solution might be to repeat earlier shared information on how to engage with the developer community, and how to build your case, and what you do when your idea is rejected, etc. Perhaps even sharing Matthew Paul Thomas's video "How to complain about Usability" might be an appropriate response. The developer community, as a whole, could also be reminded of ways to encourage involvement, to ask for prototypes, to suggest improvements, etc. It's all good and it's just stuff that we need to expect to come up, from time to time, and have some standard awareness raising responses.

I think it's best not to pre-judge or pre-guess what might be reported. We can come up with a few categories that might be expected, but we should accept all information since certainly the community voice will share messages not expected. I would venture to guess that most of the time the "solution" will be training on "how to engage" and better information sharing.

[masterchief]

Ok. How about we just role all those things into a fairly generic "I've been treated unfairly" and that will cover all those types of things?

[AmyStephen]

[brian]

Not ideal imho but what compromise solution ever is. better than nothing

[masterchief]

Awesome, hehe

[Beat]

Awesome, hehe

/me shall complain LOL.. : Forum rules bordercase: where is that tracker ?
>> No useless posts. This includes: Thread bumping, useless one liners

Actually, you could start with a "General section" then pick main subjects and leave an "Other issues" section at end. That's imho not an issue.

Important is that unhappy users get:
1) a place to complain appropriately
2) then get appropriate satisfactory replies in a timely fashion, and
3) that QA-style corrective actions are taken in a openly defined process, so that complaints don't reaoccur systematically for months, but can vary to avoid becoming boring
4) that the above is made with the will to improve the overall project quality.
5) maybe that Quality measurements can be established and monitored for non-code issues too

My concern is more about the process:

Will the process be kind of a private 1-to-1 support desk like JSupport which seems to be part of JForce, or a public open transparent trac/redmine-like process (obviously with the "private" checkbox when needed) ?

The natural general tendency (with lots of exceptions) of users and of support staff is to behave way better in public than in private (e.g. search before posting), so i'm in favor of public trouble-tickets.

Gone through public support/complaints forums, gone through private tickets on both sides, but at the end of the day, what matters is how well people and their issues are handled, not by which means.

[ewel]

I was so caught up in the trademark policy discussion that I missed a great discussion here!

Andrew, I am quite confident that I can arrange for the ombudsman of Malta, a former chief justice, to take a phone call if you want.
I expect that one of the things he would tell you is that an ombudsman has to have the balls [m/f ] to go in against what he might call the establishment, but then again things should be easier in Joomla than they are for him.
Rather than having a firm or other organisation provide an ombudsman service, I think that it would be good if the post would be filled by somebody who knows Joomla well and has a very structured, analytic and cool mind, hopefully a likable personality, and above all integrity. That may well be more important than the precise way the role is structured. The better the ticket system works, the fewer issues will remain for an ombudsman, but the more difficult and hot you can expect those issues to be.

Having said that I would be glad to help structure such a role within Joomla.
A lot of sensible things have already been said about it, how it comes at the end of the process, requires impartiality, etc. To my mind it would be best if anyone could go to him or her about anything, whether it is in the tracker or not, whether there is a tracker category for it or not, and whether it involves the leadership or not. I don't want to suggest that the project should resolve conflicts between two persons in the community, but then again if two community members get into each others hairs in the forum it might be nice to offer a place where they can be helped to solve their grievances.
At the same time, I don't think anyone needs a judge. No doubt an ombudsman will often end up mediating but he should not be a binding mediator either. Nor should we have an auditor of all human errors in the project, so the ombudsman would only act on request, and would not investigate on his/her own initiative. Primarily he/she is there to give a non-binding suggestion about what he/she thinks is best in the given situation. His or her view might carry a lot of weight, enough to bring closure, but like that you don't depart from the principle that the community/project manages itself.
One of the choices to be made would be whether an ombudsman would work according to a set procedure, or would just find ways to operate as he/she goes. I'd try to define the role clearly and leave the procedure to whoever fills the role.
Another important question already mentioned is whether or not what the ombudsman does should be transparent. In the outside world usually it is not. But in a worst case scenario, we should be aware that a Joomla ombudsman would probably not be able to claim that his information is privileged.

[Beat]

Omg, missed some posts... ombudsmen, judges, that will make community fly away fast imho. Not a good idea imho.

Make things public and allow community to help out freely. I'm amazed how things get regulated by community members on very softly moderated forums/trackers/lists. There will always be someone who will step-in and try to solve conflicts between members and problems.

Plus: public conflicts are less harse and easier to solve, as soon one or both will be looking stupid, and/or feeling so, in the light of public view.

Things get different on heavily moderated areas, where all that nice community dynamic can not happen in public at the place where it happened.

Make things transparent, accountable, public and open, and most problems will solve by themselves.

E.g. if Joomla / OSM would have clearly announced 8 months ago that you were fully aware of delays and system problems for OSM matters, and working on a solution, and informing on advancement regularly (maybe doing it in the open, getting even more community help), omg, Joomla would have saved a LOT of the built-up griefs, and gotten additional sympathy.

My 2 degrees to the oven: Stop complicating things, adding layers of control/ombudsmen/judges/super-judges/presidents, be open: Whatever you do, the Community is our final/upper Judge/Ombudsman. So only way forward is to trust the Community as a whole. That's imho not a choice.

Well, yes, it is a choice: to trust the Community and keep it, or to not trust it and live without it.

In other words, Welcome back to the Community