Re: [pcgen] More issues with RC2

Andrew,

I agree with the vast majority of what you wrote. I would like to discuss this in more depth. But it will have to wait for tomorrow as I am traveling today.

Please, everyone understand that I'm not trying to disparage anyones effort with my comments. It's very difficult to convey full meaning when they're are no verbal queues, as there is in discussions such as this. Nothing I've written is to be taken to be derogatory or accusatory, though I can see how it could be perceived as such to someone who is hyper sensitive or unfamiliar with me. I discuss and debate all the time and never get mad.

Concerning perl. I worked with perl on a small graphics cgi home project many years ago. That's an area I may be able to help with. More on that later.

In case it isn't clear, if anyone has taken my comments as a personal attack, I'm sorry. It's is not my intent. Though I will not change my behavior to be excessively passive or sensitive in order to eliminate that possibility.

I'm replying via my phone so there may be typos in the above.

Mark

---

From: Andrew Maitland via Groups.Io
Sent: ‎12/‎16/‎2018 2:28 AM
To: main@pcgen.groups.io
Subject: Re: [pcgen] More issues with RC2

Hi Mark,

The problem with an all-volunteer project, is the volunteers focus on what matters to them the most.

The main reason why Java was the language used is exactly the point of this conversation, it's meant to be a cross-platform language, without anyone focusing on the particular cultures or patterns in different operating systems.

Regarding #3 - In order for a volunteer to focus on an OS-centric issue requires the ability to replicate the problem, and the knowledge or understanding to address it. When you suggested that giving a solution to a problem was a far-fetched issue, it meant to me you thought I wanted you to find the proper solution in our own code base and submit a PR. Instead, I meant you seem to have a vast knowledge of this OS-Centric world and patterns, and would have a much easier time in pointing a developer to a website/wiki/knowledge base article/help ticket that speaks to this issue with a Java language bent. I wasn't asking you to fix the problem, but at least help out the person who will come along and try to work on it. We have Linux, Mac and Windows developers, they need a point of reference to handle issues pertaining to specific issues relating to OS.

I'm still in the dark about this abstract concept of the paper size. How does this setting even come into play? Are you using the direct print option, or does this happen when you create a PDF? I use a Standard US sized paper on a standard printer and with some crazy exceptions where the Header and body separated (page size limits exceeded in the body forcing a page break into the next page), have never had an issue with printing sheets using the PDF option (I like having a digital copy of all the characters on hand).

Next we have the perception - Yeah, the project could well be circling the drain, maybe not, the number of PRs, commits, and activity on the three main communication networks says the community is quite active and not in a death spiral. But hey perception is what people make of it.

Buggy software? Maybe the content is buggy, or there is a perception, but to be honest, most of the bugs reported are merely a typo, a feature that cannot be supported yet, or a misunderstanding of the rules themselves. I filter through roughly 50 issues in any given month. The volunteers normally resolve half of them through the online support, and the other half make it into an issue. Of those most are homebrew support, misunderstanding of the rules or in a few cases an actual issue we can address.

Now, in the grand scheme of the developer hours - Where should I ask my java developers to concentrate their efforts?

• Focusing on a working preference setting and a version misprint? (Which I have to guess is from the Windows Installer) Quick news flash, the Windows Installer has some issues that are outside of our control. Albeit both of those are very trivial issues when looking at this from a bigger picture perspective.
• Enabling the content team to implement the features from the books to make the characters rule-legal and accurate for display to the end-user? That evolutionary formula parser is a replacement project to replace two existing interwoven systems - the older system in use prior to JEP adoption, and then of course the grandfathered Licensed JEP library.
  

The Formula System is also being integrated in the talks to disconnect the UI from the code so it can be dynamic. Allowing for the code to remove the hardcoded tight coupling of d20-centric rules that have no use in systems like Starfinder, 5e, and non-d20 games.

Basically, the improvements take away a d20-focused tag system, to a game system neutral interface to allow for intuitive content creation, that focuses on single task input/output.

Now, consider this, if I were to actually lose program functionality on Windows OS, then that would be a higher priority for the team to focus on. That's a fundamental function - if you cannot use the product, then features are useless. When we lost the ability to create a MacOS build, we discovered they could still run the jar or sh file we included. When Linux users couldn't use the sh file, we scrambled to find a fix to the end of line issue and get that resolved.

It's not that we don't care about Windows, MacOS, Linux, etc., but where in the big picture does a paper printing issue, and a typo for a version number fit into the priority scale when there is no functionality loss. Who would know that the version is incorrect for your discovered method? Most users look at the top of the bar and see the version displayed there, the folder it's installed in has the correct version, so not to belittle or downplay the report here, but there seems to be a very small niche of users who would even discover the issue(s) brought up here. It's a credit to you for discovering them, but if I need a Windows-Centric professional developer to find these issues, are they really a major/critical concern in the grand picture for the development of PCGen?

Who are the active developers?

Kar & Bryan are mainly focused on PR reviews.

Tom is focused on leading the Formula System replacement. He is also working on getting the nightly builds back up and running and the web server resolved.

Eitan is focused on updating libraries, refactoring existing code and streamlining processes (He wiped out several dead libraries and a few unused files).

Javier is available to assist with the build releases and even the Windows Installer.

Andrew Wilson has been working on improving our prettyLST into TidyLST a program written in perl. And takes a look at the eccentric bugs I ask him to assist me with.

We have 5 new volunteers who are learning the code base, and focusing on either the UI or other areas of interest to themselves. I won't consider them officially active until they begin participating in the project - PR reviews, submit PRs, or collaborate on issues of interest to the team.

All of them have a task/project they are focused on.

That's the active developers on the programming side (Java or others).

For the content side, Regan and Gwen are my active book and bug fixing crew.� I have a non-team contributor by the handle of net-diver who submits a few PRs a month for fixes here and there. And I typically get one-off PRs from assorted community members with a patch of the day.

I don't believe the team is dismissive of issues, but where do the issues you report fall? What effort does it take to address them? Recall you sent me quite a list about content issues. Many of which are difficult to address correctly with the existing system, but could be managed easier with the replacement formula system. I have 20 pending content bugs waiting on the new system, and a handful of open Code requests that will drop off when the formula system takes over. One of your Pathfinder Society prestige deals required knowing whether a Skill was already granted as a class skill or not, something the new system addresses. Taken into context, the formula system replacement is a huge deal, handling a lot of outstanding issues left unresolved for well over a decade in some cases.

Your concerns are not falling on deaf ears, but either they cannot be addressed today, or they are not a high enough priority to be addressed today.

As to attracting/retaining volunteers, well, I presume when we streamline the code base into a less imposing monolith, (Drop JEP/Old System, and all the support tags tied to those 2 systems), then we will have more participation.

But you never know why people do what they do.

As to poor reporting, submit the issue in a separate post here or on Discord, and post the error. We can always request better error reporting from the code team. And meanwhile, tell you how to find and fix the error. That's why we have volunteers willing to answer questions.

Anyways, it's late and I need rest.

Cheers,

Andrew

On 12/15/2018 11:05 PM, markjmeans wrote:

Hi Andrew,

�

1. Open Office is a glaring example of why being unconcerned about OS guidelines is somehow a reason to not be concerned about a given OS�s guidelines. Open Office does honor the default page format in Windows; and it supports multiple cultures; and it supports multi-OS. I have felt for some time now that PCGen considers Windows as something that needs no particular attention to standard Windows patterns and practices and is mostly only supported because Java happens to support it. The responses to this and other issues I�ve brought up in the last several months do little to assuage that feeling. It may simply be that there are no Windows centric developers to take on the mantle to assure that Windows guidelines are honored with conditional compilation code segments where appropriately divergent from Unix-isms. I completely understand that this is a volunteer project. But everyone in the PCGen development team is surely aware that this project appears to be in a slow death (fewer and fewer volunteers) precisely because Windows users (the largest desktop segment) is going to Hero Lab and other software due to the perceived buggy nature or usability issues (deserved or not) of PCGen. I don�t want that to happen. I would like to see what is probably the projects largest user segment to be so happy with the core usability of PCGen that we attract many new volunteers. That extends to the code team as well. From what I�ve seen so far that the new formula parser is evolutionary. But to get new volunteer coders you must first get their attention. And that becomes more difficult as the audience declines.

�

2. The issue with this is not that a homebrew is broken. It is that PCGen gives no useful error message to tell someone WHERE it is broken. In my case, this homebrew is little more than a huge multi-set and commenting out all the lines in the PCC file to find out which line is causing the issue is something that no other homebrew user *should* have to do. The error message for the load failure should be enough to find out what the issue was. In this case, after uninstalling PCGEN and reinstalling and making sure to select the _universal and the other _xxx entry the error did not recur.

�

3. As for the source. Like I said I know very little about Java programming, and less about the specific coding in PCGen. For me to spend, probably hours, digging through PCGen to understand its internal structure enough to submit a PR for the code is ridiculous on its face. The chance that I could even attempt to identify a fix that would not have unintended consequences without such study is presumptuous at best.

�

As for the remainder of your comment� Try developing two different programs, pascal and C, at the same time. The languages are so close in syntax you quickly get mired in the peculiarities of the two and spend a lot of time bug-fixing and referring to API docs. This is not efficient coding. Efficient coding is 100+ lines of debugged functioning code per hour per developer, not 700+ lines of code per month per developer. As an example, in the summer of 2005 I started writing a Windows XP application that was ready for deployment in 9 months. It had over 100,000 lines of code (comprising modules written in VB, C++, and 8051 assembler), not counting auto generated code from UI creation tools I used. And not counting the code from the early parts of the project that were deleted or replaced as it was being developed. There was only myself and one other developer working on this project. I produced 95+% of the VB code (the bulk of the application), perhaps 10-15% of the C++ code (high level USB driver inte

[The entire original message is not included.]