[azxten]

Originally Posted by nilbog [You must be logged in to view images. Log in or Register.]

If you think negative rhetoric will push me to do something you want, you're incorrect.

This issue is on a short list of content upgrades I plan on completing. It is not as simple as others; there are various mechanics features involved which require extensive effort and testing.

With all due respect sire, it is.. most unpleasant.. to be told not to bump a thread unless more information is available or a significant time has passed and then multiple years pass with no additional response.

https://www.project1999.com/forums/s...d.php?t=395711

As I've mentioned creating a new staff member position like "Lorekeeper" who filters bug reports and updates a visible status would be exceptionally helpful for those who want to contribute research and more on this forum.

This group of people can be responsible for filtering out garbage, bringing you the bug reports that are worth review, and then updating their status based on your feedback.

Potential status:

1. Open, no one has reviewed it.
2. Lorekeeper has reviewed it, garbage, not a bug, duplicate, previously discussed, etc.
2. Lorekeeper has reviewed it, needs more research.
3. Nilbog has reviewed it, needs more research.
4. Nilbog has accepted the bug as legitimate and it is part of the backlog to fix.
5. Fixed.

There seems to be a lot of effort here being wasted when people keep researching things that are on the "short list" already or get disgruntled when they can't get any response about their efforts so they just stop contributing.

I would reverse engineer the client to figure out the classic Charm code but I feel it's wasted effort until channeling gets fixed because it seems likely that such an effort might never materialize into any changes. Also what if you already have the classic Charm code figured out on your short list and I don't know? That would be a lot of wasted effort on my part.

Without adequate communication on posts and visibility into this "short list" of confirmed issues and the work needing to be done on them we have a very disjointed volunteer contribution process that leaves a lot of people feeling rejected. The indication provided here by staff is that volunteer efforts are encouraged and desired but you have to balance this with the reality of the experience of trying to contribute which gives the opposite impression that the staff would rather we didn't bother them or that we can "try" to contribute and the staff "may" bother to look at something. This disconnect is the source of a lot of those feelings.

It would be better if the messaging was more clear up front that you can't expect any kind of response or follow up but if you want to post go ahead OR if the staff would implement better management of the issues so that each contributor felt their efforts were being acknowledged.

I would again encourage you to read this sticky, "Please read before posting" on the bug forum.

https://www.project1999.com/forums/showthread.php?t=19

While a lot of you have been contributing a lot of bugs recently, which is awesome, we have a high standard of accuracy / evidence. While we don't need a congressional hearing about every bug fix, throwing us a link to something definitive from a waybacked site is the most helpful thing you can do, other than pointing our attention to the bug itself. It helps us make the change with confidence that we're doing the right thing.

With the new round of beta testing, this is highly relevant.

Please make sure to include all the information you can about an issue.

I'm wasting a lot of time reading posts with no research or links.

What is the bar of evidence approximately and when has it been met? We don't know and almost never do you hear that it has been met. Things go from "needs more research" to "shut up I'm working on it" or "fixed in next patch" which creates a tension and negativity when you're told to dig up more research when you already have a ton of research only to later find out that some amount of research in between there wasn't needed. This is the "congressional hearing" outcome Uthgaard refers to where people just argue endlessly in bug threads about that bar and if it has been met or not. Also note the trolling in this thread of the people actually contributing research and then over the course of years you do come back and post about negative rhetoric. Threads devolve into this because of the way the forum operates. Someone who contributes research, gets told to do more research with no bar, gets told not to bump unless "significant time has passed" only to see things idle for years, gets trolled the whole time during this, is naturally going to end up in a pretty frustrated and negative place.

If you're still wasting time reading posts with inadequate research or links, and this thread must be another example since you commented it needs more research, then consider the Lorekeeper idea I mentioned above. Volunteers like Dolalin or others could filter these bug reports so you don't waste your time and can spend your time responding and reviewing the things that probably should get a review/response because people put in the effort to contribute something worthwhile. It would likely be a lot easier for you and better for volunteers if there was a go between who brought you a list of a dozen threads that were solid and you could ignore the rest and those people who made those dozen threads actually get a response and follow up in a timely matter about if they should keep researching or can consider the matter tracked and "done" on their part.

One final note on this particular change is you mention it is more difficult than others to implement. Is it possible the work could be broken down into sub tasks and into two groups where one is possible to do with the EQEmu code and the other requires access to P99 source? This would allow you to say, "Ok this is an acknowledged bug, the research is good, we (staff) have some changes we need to make but in the mean time someone should be able to adjust X, Y, and Z using EQEmu open source code please contribute those changes here if you want this to get done sooner." This would also require the staff inform people though if they decide to do X, Y, and Z themselves to avoid that duplicated effort. That could also be a matter of doing all the private source work first and then dropping a note, "We completed our changes and are working on X, Y, and Z ourselves now."