Can BEE be modified to allow category creation for countries who choose, and not for those who don't [closed]

Question

Is it possible for BEE to be modified to allow category creation for some countries and not others? In other words, could individual country projects be allowed to opt out? Or is that too complicated technologically speaking?

This question was asked on a recent G2G post and was never answered by the app developers.

A comment was made that a pop-up was utilised for part of a country's location categories, advising those categories would need to be created manually.

Could that pop-up be utilised for all of a country's cemetery OR location categories, if they so requested?

Could it be used as an interim measure, while a country evaluates their participation?

Assuming that is technically possible, can a country's Project request that facility for their country's cemetery OR location categories?

Comments

Good suggestion, Margaret. Until BEE is fine-tuned to handle all the complexities of a given area, this would avoid categories being created with errors which require work by project members to correct, and would also make life easier for the developers themselves by relieving the pressure of complaints.

---

I agree with Jim that you asked a good question,

---

I agree with Jim also.

Answer 1

My question is -- why should a country project be able to opt-out? Instead, the project should work with the developers to adjust it to follow the project's guidelines.

Having it fine-tuned to the project's guidelines will save whoever is managing that part of the categorization structure time because they won't have to respond to as many new category requests, and everyone will benefit as people are more likely to categorize a profile if the category already exists.

Comments

The idea of an interim measure could be that general WikiTree members cannot create categories with the app before it is fine-tuned for a particular country. That would lead—and apparently has led in some cases—to incorrect results requiring labour to fix. Once fine-tuning in a testbed version of the app has been done by collaboration between the app developers and expert project members with knowledge of the country, the project will be able to check that everything is working correctly, and when they are satisfied according to reasonable criteria, the app can be released generally for that country.

This does require a willingness to cooperate on both sides, developers and projects. I don't know whether any projects have declined to collaborate, but there does seem to be evidence of the app being made available for some areas before fine-tuning has occurred.

---

Jim has said everything I would have said, and more.

The fact remains, the question was asked by a Project leader in a previous G2G post, and we have yet to hear an answer from the app creator, one way or the other.

Given that there has already been one fault identified (since released to numerous countries) that could have resulted in many existing categories having their painstakingly researched data overwritten by possibly incorrectly data, it's not surprising that possibly other countries might like to take their time evaluating it for their country, before deciding if it works well enough for them. Luckily that major fault has been rectified, after a great deal of angst on both sides. There doesn't need to be a repetition of that situation, surely projects should be the ones to decide, if and when they are ready for their country to be in the live version, be it for cemeteries or locations.

---

@Jamie: everyone will benefit as people are more likely to categorize a profile if the category already exists

Which has always been my argument for creating empty categories!

---

This is not entirely true, David, as the US Civil War categories were pre-created and I FIX those categories EVERY SINGLE DAY. The categories are there, but many people seem to add categories exactly as they see the unit named in a record. So, I am  not really sure that pre-creation saves any later work.

---

My question is -- why should a country project be able to opt-out?

The primary reason for considering an opt-out option, at least temporarily, is due the occurrence of errors stemming from the app's current implementation.

While the app aims to streamline the categorization process, it's not fully aligned with the specific guidelines and nuances of each project, so it is leading to errors in categorization. These concerns aren't just theoretical; they reflect actual errors that are actively occurring. These errors not only create additional work in terms of correction and oversight but can also lead to confusion and inconsistency within the project's own categorization framework.

Allowing a project to opt-out provides the necessary time to address these issues (as noted below) and ensure that the app's functionality aligns more closely with the project's specific needs and standards without continuing to generate errors.

Instead, the project should work with the developers to adjust it to follow the project's guidelines.

Efforts have been made in this direction. For example, in this discussion, I noted that there were errors and asked for it to be temporarily be disabled while we collaborated on a solution. So far, there has been a noticeable lack of collaboration or action towards resolving these issues, other than new features like: "BEE will show a warning, if there already is a category using the same cemetery ID from Find a Grave." and "Also the manual now contains a passage that explicitly links to the cemetery guidelines."

To date, the errors identified continue to exist. So this raises an important question:

Are the Categorization and Cemeterist projects now expected to shoulder the responsibility of identifying and correcting these errors?

This situation places the burden of maintaining category accuracy on the users who are impacted by the tool's shortcomings, rather than on the tool itself or the users who are utilizing it.

---

The OP makes it sound like countries should have the option to opt out permanently, not temporarily. I don't agree with the option to permanently opt out.

Making G2G posts asking a particular person a question instead of just contacting them directly, and then complaining when they don't respond to your G2G post isn't a lack of collaboration on their part. If you have a question for a particular person, contact them directly, and remember that they are also a volunteer so be patient.

---

This is back to front, Jamie. The job of software developers is to satisfy the needs of users, not the other way around. I agree with you that permanent opt-outs shouldn't be available, but Margaret also spoke of interim measures. Blocking the app from causing errors until it is demonstrably ready for a particular area is the right thing to do.

When there is a general problem affecting a number of areas, it's sensible to discuss it openly, rather than having a whole series of bilateral conversations.

---

@Jamie, I apologise if the question sounded demanding, such was not the intention. The question had already been asked in the previous discussion, by someone else, had generated some comments and seemed to have been "lost" in so many other questions and answers.

As the question, and subsequent answers, may have been of interest to projects that have not yet been configured to BEE (rather than my own, which has already been configured for cemeteries) I thought it was best asked on G2G. It was not intended as directed at one particular person, as Florian mentions in his answer below, more than one person is involved in the technical development of BEE, so having the answer to a technical question may not rest with one particular person.

I apologise if it came across as "complaining", again that was not the intention.

I have been in constant one-on-one communication with regard to our project configuration for cemeteries which has already been implemented.

---

The job of software developers is to satisfy the needs of users, not the other way around.

Yes, but projects being able to opt-out a country permanently would be ignoring all the users who aren't part of the project but have ancestors/interests in the area of the project. I'm glad that this doesn't seem to be what is being asked for.

Answer 2

Irish cemeteries are a bit of a nightmare as far as naming on Find A Grave goes and the locations are a problem as well. I hope that before BEE/WBE is activated for Irish cemeteries we will have a period of consultation with the Ireland Project.

Ballysheil is a point in question as I happen to be looking at it. There are two graves on Find A Grave but as far as I can tell there is no graveyard in Ballysheil, County Down and according to Bing

Ballysheil is located in County Down, Northern Ireland. However, it seems there might be a slight mix-up. Ballysheil is actually in County Offaly, not County Down.

I think their AI is a bit dulally-tap. Googlemaps the same. Only finds Offaly however there is definitely a townland Ballysheil in County Down.

Comments

For British and Polish cemeteries I get the parent categories from WikiTree+, for some Canadian provinces I ask the user for the county. One of those approaches (or a combination) should also work for Ireland, I guess.

---

Florian, unfortunately WikiTree+ uses FaG as its comparison DB, so doesn't answer David's items.  And in this province, counties get changed like people's underwear almost, so going by them is a massive headache.

---

Danielle: When searching for location (sic!) categories to be used as parameters in cemetery categories, WikiTree+ uses only WikiTree data, with which we should be safe.

Answer 3

Let me start by saying that although I am a member of WT_APPS, I do not write with authority for that team. I am merely the documentarian for WBE. Also, as a newly minted PC for the Acadian Project, I do not write with the authority of that project. I am writing as an interested WikiTreer.

Y'all are asking the wrong questions.

BEE is software. It can be programmed to implement any logical restriction.

The developers of BEE don't consider the proposed restriction to be logical. 

Most of the argument, it seems, is that some Project Leaders and/or Project Coordinators and/or and Team Leaders have taken positions in favour of a restriction. 

https://en.wikipedia.org/wiki/Argument_from_authority

Meanwhile, Jamie has asked again: "why should a country project be able to opt-out? Instead, the project should work with the developers to adjust it to follow the project's guidelines."

By way of analogy, please cast your memories back to the advent of the 'spell checker'. When it first appeared on my computer, it was able to deal with American English and British English; it was also able to deal with French French. Eventually, the developers were able to accommodate Canadian English and Canadian French. But you can be sure that Microsoft and Apple would not have considered blocking Canadian users from using their spell checker.

I observe that WikiTreers want a way to manage categories. Many of them, worldwide, have been willing to work with the Apps team to achieve results.

I further observe that Ian and Flo have offered to work with anyone who is willing to help them to configure BEE so that it works optimally for their country and/or project. That's a big commitment, but they want to solve this problem. 

For some countries and projects, the specifications for how to properly form categories are very straightforward and logical, and BEE has been able to meet their needs easily.

However, some countries and projects have more complex, and in some case convoluted, rules for how to form a category. Members of WT_APPS have not challenged those complexities, but rather offered to work with those projects to codify their rules in BEE, with the belief that it is better to unburden the user from having to understand all of those complexities.

I often wonder whether all of those complexities are needed. And, just maybe, that's one of the right questions to ask. 

BEE and WBE have staked out a problem space, Category Creation and Management, that it intends to fix. 

The best question to ask: How can we help achieve that goal, for all WikiTree-kind?

Comments

Murray, the communication and the programming required to configure BEE for a particular country or project take time and effort. In the interim before this is complete, the app will be generating errors, unless its use for that area is temporarily turned off. It is sensible not to release software for a specific task until it is ready. The examples given by Steven, among others, demonstrate that so far the app has sometimes fallen short of this principle. Allowing temporary opt-outs would remedy this.

---

1. Yes, it takes time to configure for a specific country/project. Best to get started.

2. The app will only generate errors when it does. The same can be said of human operators.

3. The app is perfectly ready to accomplish its task. Apparently the some of the countries and projects are not yet prepared to provide specs to their category creation rules.

4. There have been many assertions about the supposed problems caused by BEE's category creation tool, there has not been much in the way of evidence. I don't know about you, but I would like to see evidence that the use of BEE by WikiTreers has recently introduced a disproportionate number of flawed categories. And then I would like Ian and Flo to study those examples to learn how to do better.

5. As Ian Beacall is quick to point out, if you don't like a feature, you don't have to use it. Project leaders are welcome to ask their members not to use BEE to create categories.

6. Members have been quick to tell Ian and Flo that they do want to use BEE.

---

I don't feel the spell checker analogy is appropriate; as errors introduced by a spell-checker only affect that user's document. Whereas errors in WikiTree categories affect everybody and create more work for volunteers already under a heavy workload. As well as more server load -- EditBot is already under a backlog of category renaming.

Your point 3 supports the original assertion. It's not about "whose fault it is" but the fact that specifications do not exist for category creation rules in many cases.

Your point 5 is not a solution , because categories can be created by people who are not members of the project. It would only work in conjunction with WT requiring project membership before a category can be created under that project.  (Maybe that is worth discussing...)

---

@Jim: To configure the app needs time, true. But in my opinion, it is best to invest the time in correct configuration (from all sides, country/cemetery project and apps project) to create a correctly working app. In the long range, it will save the users of the app very much time and create correct categories.

To opt out permanently would be no good move, because this would put the discussion down in the projects when a user wants to use the categories and has to fight to be able to do so.

---

I agree, Jelena, both with not rushing the negotiations or implementation through "rapid advances", and with not permanently opting out. See also here.

---

Matt,

First, thank you for responding to my post—I have been feeling ignored. And thanks for addressing these points.

To be clear, WikiTree allows category creation by members, without regard to project membership, national affiliation, or the omnipresent worries of project leaders. If that is deemed to be an actual problem, somebody should file a request for a rule change.

Any 'error' that I (or any member) makes with respect to adding a category does not necessarily imply any greater workload for anybody else. (Straw man argument.) As I have written elsewhere, what a project leader might consider an 'errant category' is actually a perfectly useful Cultural Category in the eyes of the user (and his community) who created and populated it. And it then becomes a candidate to be merged/transformed into an Institutional Category. Win-Win.

The fact that merging of categories consumes resources is not really pertinent, in my view, as the same holds true whether one uses BEE to create a Cultural Category or one does so without the assistance of BEE and WBE. (Straw man argument.)

As a reporter, the fact that category creation rules do not exist in many cases, or that the project leaders have difficulty explaining those rules would seem to be the crux of the problem that BEE is addressing on behalf of WikiTree members who have become impatient with this sorry state of affairs.

I am hopeful that BEE will serve as a catalyst, giving projects an opportunity to finally codify their category creation rules, which will benefit all of their members (and non-members), and will allow the developers to implement those rules. That will give members greater agency, and help to eliminate users' anxiety about creating categories. Rather than having to seek a high-priest to invoke magical category-making incantations, they will be able to simply press a button.

My point 5 is a solution that I offered only to the extent that project leaders can encourage their members to avoid BEE's category creation tools. (I was being somewhat facetious in order to make the point that project leaders do not actually have any 'authority over' their members.) Yes, non-members of the project would still be free to use BEE as they choose, which is what we would expect on WikiTree. Unless a project has asserted PPP over a profile, then average WikiTreers are free to edit post-1700 profiles at will.

People are going to make mistakes, and other people will correct them. That is the nature of a Wiki. We live and we learn, and the developers continue to improve their tools so that everything will improve for all of WikiTree-kind in the fullness of time.

Answer 4

I initially expected users to see that BEE cemeteries don't work for their country yet and to reach out and help improving it, like I wrote on the BEE page and the introduction post. I'm still not sure if many people are actually using BEE to create cemeteries for "the wrong" countries or if this is just a general fear that is being promulgated without any data behind it.

Some days ago, independent from David's request about this, I tried to make the cemeteries part of BEE return just the basic category source code for unconfigured countries, like it does for non-supported Wikipedia pages. But I ran into big technical difficulties and didn't follow-up on the idea. This weekend, Ian helped me to implement the support "user-specific custom parameters" for category templates, after I had run into similar problems. With Ian's work in place, it makes sense, to try again to make BEE return source code instead of a category preview for unconfigured countries.

But as long as there are people supporting and advocating its use by specifying and testing for one country or region, I will not implement any country blocks for configured countries!

Comments

Logic Chopping: Using the technical tools of logic in an unhelpful and pedantic manner by focusing on trivial details instead of directly addressing the main issue in dispute.  Irrelevant over precision.

'harping on ''authority'' for someone in a leadership or coordinator position is verging on insulting.'

It seems to me that this statement is inappropriate. I am here acting on my own behalf as a member of WikiTree, not as a spokesperson for any of the projects in which I am a member. I made that clear at the outset of my comments.  I am reporting on the situation as I see it, and I am fully entitled to do so.

I 'harped on authority' with regard to various attempts at 'argument from authority'. 

I also 'harped on authority' with regard to the developers view that project leaders are not the only arbiters.

I don't agree that this was 'logic chopping'. The arguments that I challenged were central to the issue and how the issue was being presented. I would say that I dissected the arguments as a scientist or a lawyer would do, to get to the essential truths of the situation.  

I have had no intention to 'insult' anyone, and certainly not you. But, as a member of the Quebec project, I do find it difficult to work with categories. I have had to call on your assistance to create categories in Quebec, and I expect to have to do so again. That's not intended as a sleight against you. I am confident that you (and Amy) have done your best to make categories work. But as a member, it remains difficult for me to create conforming categories. I think that we (WikiTree) can do better, and the developers of BEE think so too. 

I have written that I thought that some of the category naming rules were a bit convoluted, and you yourself have reported here that there are some oddities about naming Quebec cemeteries. The fact that the rules seem convoluted is simply an observation, not intended to insult, just an observation of fact. Even so, the developers are perfectly willing to work with you (and other project teams) to codify those practices, with your active cooperation and participation.

(And, by the way, I don't personally use BEE because it doesn't run on Safari, and even if it did, I lack confidence in my own ability to get everything right anyway. So, I will continue to rely upon you to create categories for the Seigneuries in Gaspe and elsewhere in Quebec.)

For the record, I acknowledge you (Danielle) and Amy as experts on the subject of categorization in Canada. I'm totally down with you representing your projects and advocating for what you need to achieve your goals. I am hopeful that you and the developers will work through whatever needs to be worked through. 

If I had thought it appropriate to write about people's feelings, I might have had a lot to say. (I have certainly heard from other members.) I think, and I truly hope, that I have not attacked anybody personally, even while challenging some assumptions about the power dynamic between the project leaders and the apps developers. 

I understand that my reporting may cause some upset because I have put forward positions that have previously remained unspoken. Again, I have no intent to insult anyone. My goal was to calm the waters, toss aside illogical arguments, and encourage dispassionate discussion. 

Your faithful reporter,

Murray Maloney-2332

---

Rejection of arguments because of their form, logical or otherwise, carries little weight as a substitute for addressing their content. The core issues here are ones of human relationships, not logic. It's a vital part of responsible software development to listen to and understand the requirements and concerns of all users. There is much room for improvement on this.

---

Jim,

Rejection of arguments because of their form, logical or otherwise, carries little weight as a substitute for addressing their content. 

Carries little weight with you apparently. The developers would disagree. Just as in science and the law, it is first necessary to dispense with irrelevant/illogical statements. It is really a waste of everybody's time to debate statements that are illogical on their face. More importantly, it is necessary to clear the table of unhelpful rhetoric that prejudices the discussion.

The core issues here are ones of human relationships, not logic. 

Indeed. Why can't we all just get along.

It's a vital part of responsible software development to listen to and understand the requirements and concerns of all users. There is much room for improvement on this.

Indeed.

The developers listen the concerns of all users. To suggest otherwise is not only disingenuous, it is utter nonsense. I can bear witness to the lengths that Ian and Flo go to create useable software. The interviews that they conduct with users. They G2G posts soliciting input. The testing. Not to mention the relentless documentarian who tests and challenges every feature. 

It's not that they are not listening, it is that they sometimes disgree with the stated requirements of some users, and they use their best judgement to make the software that they believe is best suited to the users needs. (Just in case a reminder is needed here... they are also WikiTree users and therefore entitled to their own say, they are self-employed, they have the skills to implement their will, and they actually do the work.) 

So, it's not the case that they are not listening. It is the case that you are not getting exactly what you (plural) want. And it is also the case that, having not gotten what you want, you keep coming back to the same post with more unhelpful rhetoric.  

I should note that the need for interpersonal communication is not a one-way street. I observe that many of the participants in this discussion have not deigned to respond to some of my/Ian's/Jamie's posts. It's almost as if we are being ignored. That somehow our views are less important in the scheme of things. It's always "Ya, but...". It would be nice to see some, "Oh ya, you make a good point."

And rather than addressing the issue, we are engaged in a red herring discussion about whether it is appropriate for me to challenge illogical statements by those who are promoting this false dichotomy. 

As far as I can tell, on Tuesday 14 Nov 2023, Ian and Flo are actively soliciting input to make BEE better. So far as I know, they are not spending any time thinking about a moratorium on BEE, and they consider the entire discussion to be a needless distraction. I support them in that view. 

I encourage you to find a way to work with Ian and Flo that does not involve asserting that they are not performing up to your standards, because that is not helping anything.

As others have attested, when they worked with Ian and Flo, the result was satisfying. Could we maybe we could hear a bit more about that? About how they actually do listen to users and help make WikiTree better for all? 

Or maybe, while you were writing about better communication, you weren't actually wanting to listen (read) yourself, but rather wanting to persist in making demands, in the face of outright rejection of your proposal. And not only that, but then to cast aspersions. We can all do better.   

---

We have seen two examples in these discussions where a developer discounted the requests or statements of somebody, in one case in favour of another which agreed better with the developer's preferred viewpoint, and in the other where a perfectly correct warning of risk was ignored until "evidence" was available, when it was quite obvious to most people that the risk was high. This is why I counsel for the development team to reflect on and improve its approach to listening to all users and hearing what they are telling you.

Long-winded and repetitive criticism of the way others present their arguments is another form of discounting. (I think this partly explains why you are not getting very many replies.) Please instead try to understand what people are upset about and why.

---

Thank you, that is much better. I appreciate the moderation displayed in your first paragraph. (Perhaps my 'long-winded and repetitive criticism of the way others present their arguments' has had a positive impact.)

Yes, I think that the developers do understand what people are upset about. I think that I do too. I know that some people were put out and then had to do some extra work that they might not have had to do otherwise. (I don't mean to minimize. I do sense the tension.) 

Stuff happens. Yes, warnings were issued. Not everything went as well as the developers had hoped. Perhaps that was incautious of them. And, perhaps it was a small price for this kind of advance in WIkiTree category technology. The jury is out. It seems to me that the developers learned from a bad experience and acted quickly to remedy the situation. I know that some people were put out and then had to do some extra work that they might not have had to do otherwise. (I don't mean to minimize. I do sense the tension.) 

How about you try to understand the developers by talking to them (and me) without all the rhetoric? That 1st paragraph is really good. (Except for the assertion of high risk—I think we know there are no 'high risk' situations in the world of WikiTree, unless WBE gains the power to do an 'cd /; rm -rf' and even then I think we could recover from Aleš mirror or from backups.)

You can characterize it as discounting, which it is in a sense, but I see it as sharpening Occam's Razor upon the Fallacies of Logic. The developers are logical people (and I like to think that I am too) and they are trying to solve a logical problem using the modern tools of logic. So, it should be no surprise to learn that they prefer logical discourse and detailed specification, which is what they have asked for. We can save the group hug for later.

---

Broad consultation and a risk assessment would have meant that the dangerous category edit/overwrite feature would never have been released in the first place.

You haven't asked, but the reason I am upset is that a WikiTree member whose labour and passion I appreciate and admire had requests rejected or neglected twice, in one case with disrespect and the other with insult.

---

Jim,

That's right, a broader consultation and risk assessment could have prevented the recent category data loss event. I get a real strong sense that some of you consider this event to have been a major catastrophe from you which you may never recover, and I'm only making fun of that because I have lived through a plane crash. So, I guess it's a matter of perspective.

That's right. I had not asked. Nor you I. Anyway, that's news to me and it seems that may have affected you. So, I'll admit that I have been recently affected because a person who I admire and respect has felt disrespected and insulted.

So, rather than going on about the trauma of it all and how mean somebody was to your friend... can we get on with the actual work of empowering the WikiTree category creation and management tool to make WikiTree better for everybody. Smoke the peace pipe?

---

The problem with the edit/overwrite feature incident was the apparent attitudes it illustrated in the development team, including reluctance and slowness to hear what people were saying, and at one point discourtesy verging on hostility. You haven't mentioned the other incident I cited. If you're saying that someone in the team has also been disrespected, that shows the danger of setting out on such a path oneself.

To help things to go forward on a better footing, as I've already in part said, the development team should reflect internally on how it listens and communicates, learn lessons from the mistakes it has made, and understand that moving in "rapid advances" without allowing projects time to provide input and testing is not a good strategy.

---

Murray:

So now I find that the Australia Project is accused of "demanding a moratorium on apps". I've been right through my comments on this post and can find no reference to such a statement, nor do I believe I made any such demand on the previous G2G post. I'm a big user of WBE and have told Ian and Florian on various occasions how beneficial I find many of the features. Many of our project members (and others) I know use and love various apps. 

It seems that you have made that accusation based on your interpretation of the wording of the question. Let's just have a look at some previous comments I made:

Firstly, thank you Florian for providing some technical information to answer the technical question, regarding currently unconfigured countries in cemeteries and/or locations. The question was never meant to apply to already configured countries (well not in my mind anyway).

I reiterate again, this original question was on behalf of as yet unconfigured projects/countries in cemeteries and/or locations. our project is already configured for cemeteries but not yet for locations.

@Jamie, I apologise if the question sounded demanding, such was not the intention. The question had already been asked in the previous discussion, by someone else, had generated some comments and seemed to have been "lost" in so many other questions and answers.

As the question, and subsequent answers, may have been of interest to projects that have not yet been configured to BEE (rather than my own, which has already been configured for cemeteries) I thought it was best asked on G2G. It was not intended as directed at one particular person, as Florian mentions in his answer below, more than one person is involved in the technical development of BEE, so having the answer to a technical question may not rest with one particular person.

I apologise if it came across as "complaining", again that was not the intention.

I have been in constant one-on-one communication with regard to our project configuration for cemeteries which has already been implemented.

Now after those comments were made, Florian thanked me for making them, he certainly didn't indicate to me that he thought I or the Australia Project was "demanding a moratorium on apps".

Florian filled in a bit of a gap for me in this comment, and I subsequently made these comments:

Florian has indicated his reason for going ahead with our configurations, and since then he has managed to find a solution to a different issue that we both are happy with. I acknowledge that we have differing opinions (to which we are both entitled) on the role of Projects and project leaders in this process, and knowing that, enables me to adjust my ongoing actions within our project accordingly.

Now that I know how the interaction between a project and wt-apps works (or doesn't), I can adjust my actions accordingly, going forward.

Your imagination may tell you that means as a Project, we'll be using our "authority" to tell members to "not use apps" to create categories, (based on your earlier comment: But I wouldn't let my project leader tell me which tools I can use, or whether I can create a category to record the profiles of all the people who share a graveyard with my 2nd great grandfather.)

I was thinking we'd be saying something along the lines of: We now have a third way to create cemetery categories, BEE is now configured for creating Australian cemetery categories. If you do use BEE to create a cemetery category, it does use FG as the basis for the name and location of the cemetery. As we know FG is frequently incorrect, especially with location, the same checks need to be made that we do when creating a cemetery category manually, to find the correct info. Then I'll probably mention there's an option coming real soon to add extra parameters to the CIB (instead of adding them manually). I might even that mention that at some stage, locations will also be configured, and at that time, any of us who are testing for BEE might like to be in contact, so we can compare results etc. It might even be possible to set up a discord chat between us and the developers so we can share results and feedback.

Moving on, the words "allow" and "countries who choose" in the question seem to be causing you some consternation, so is this where the "demanding a moratorium on apps" comes from??

Indulge me if you will, in a short story:

After the initial post on G2G announcing that BEE was going to be used for creating cemeteries, I subsequently went to the BEE page and it says: 

This feature is currently optimized for cemeteries in the England, Germany, Poland, Scotland and the US. Feel free to reach out to Flo about special treatment for your region/country.

The G2G announcement expressed similar sentiments, If you need country specific optimizations or additions, feel free to reach out to me

That particular wording, to me, at the time, signified a "choice", that if and when a project decided they wanted specific country configuration, they contacted Flo, and went from there. There is nothing there to indicate any lack of "choice". I figured we'd consider for a bit, think about how it would work here, see how it worked with the existing countries, and go from there. Shortly thereafter, I see on a G2G post, that Australia will be available very soon. Australians just don't like being blindsided and put on the "back foot". 

Now that we all know there is no "allow", no "choice", then could I dare to make a suggestion?

That the BEE documentation page be made a lot clearer to tell it like it actually is? Maybe something like:

This feature is currently optimized for cemeteries in <whatever countries>. Eventually, all countries with cemetery categories will be configured for BEE to be able to create them. When we come to look at a particular country, we will contact the relevant project to seek input on the particular treatment that may be needed for that country. If possible, a discord group message could be set up with the developers and members of the country project to give and receive feedback.

Edited: It doesn't have to be the app developers, who make contact with the country involved, bound to be someone in the wt-apps project who could shoot out a quick message.

Well that's my suggestion, for what it's worth.

Almost last but not least, I think it's time we all stopped rehashing the overwriting situation, we all know what happened, how it transpired, and the end result, it was fixed, and is no longer an issue. We've all learnt a lot since then, and we all have other things that need our time and attention.

Murray, strangely, I find your claim that the Australia Project is "demanding a moratorium on apps", much more offensive than your comments on me and my "authority". I don't know how it works in your project, but in the Australia Project we don't "demand" anything from our members, or from other WikiTreers, Given that this question was about a specific aspect of BEE, not apps in general, then I am at rather a loss to work out how you came by this particular claim.

---

Margaret,

[Edited after I found my offending text.]

I wrote: "While I support your role as a spokesperson (and negotiator) for your project, I cannot support any project insistently demanding a moratorium on apps.

"Did I misunderstand that part?"

So, apparently I did misunderstand that part. Thank you for bringing that to my attention. My phrasing was poor. I should have said:

a) I support your role...

b) I don't support calls for a moratorium on BEE

To be clear, I don't think that I ever intended to '''accuse''' anybody of anything. I have objected to the way that some people have presented arguments, but I think that I mentioned that it seems that your role in all of this has been constructive. In particular, I noted that due to your working with the developers, the sky was not falling in Australia. Perhaps I should have been more generous in giving you credit for your sincere efforts. So, to be clear, I commend you for how you worked with the developers, and your reporting here. 

I don't think that anybody involved in this protracted episode has had any bad intentions. I do think that emotions may have run a bit hot, and some people may have uttered words that now seem a bit overwrought in retrospect. If you have interpreted anything that I have written as being an '''accusation''' then I apologize unreservedly; that was never my intention.

It has been my intention to try to get everybody to calm down, be objective and logical, and not throw around '''mean words'''. Several people have, either privately or publicly, expressed that their feelings have been hurt through all of this, or that they have been disrespected/insulted in some way—PLs,developers, users. While I sympathize, there is nothing that I can do to ameliorate that pain.

I agree that this thread has gone on long enough.

Answer 5

Why are people assuming that because an error exists, that somehow it implies that it must be corrected, or that it "adds" to a workload?

These are indicators of things which *could be * improved, not requirements, and any expectations that anyone can zero out the error reports has a misunderstanding of what they are.

On the whole, having a category added with an incorrect parameter is a win, with an error popping up to show how it could be even better. Not having that category at all would be less useful than the error.

Comments

Good point, Jonathan. The user usually creates a category, because they want a profile categorized. Every categorized profile is a win, even if one later has to merge the category with another one or change some parameters, because it's one profile less one has to search (and find!) for the "at one point" created "perfect" category.

---

Jonathan, error by definition needs to be fixed if we want the system to be consistent.  And having to fix errors does indeed add to the workload.  If it was right in the first place it wouldn't need fixing.

---

I'm with Danielle on this.

Yesterday, I went through the error report for all Italian location categories and it took me the whole afternoon. There were a lot of wrong coordinates, caused by copy mistakes (which shouldn't happen with BEE), a few wrong aka templates. One error for 92 (!) categories by myself that I didn't know was an issue, otherwise I would have done it properly from the beginning (here, I had to create the correct category and delete the old one, which would have taken me hours without the technical support of Flo). And one duplicate category (which also won't happen with BEE).

---

My point is that we will never be able to work these lists away,  that is not the intent, it is to call attention where needed to improve things in an incremental and focused way.

Nobody should feel pressured by them, and nobody expects anyone to "complete" them.

However,  we are gaining accuracy and categorization data by having the BEE add what it is adding. If people can identify opportunites for the BEE to get even better, then great! But lets not let the perfect be the enemy of the good.