Input gathering: who can help make language decisions, and how (e.g. Language Advisory Board)

Further to various discussions on a Language Advisory Board, can we:

  • Do things differently from the way this has been done in the past to make it more successful
  • Bring any other ideas around making this work in an open and pragmatic way

Again, please try to keep discussion to positive action that we can take. I speak for myself, but I do know that LAS are keen to get something in place and up and running ASAP, so opinion and input is very welcome.

I’ll be taking the liberty of moving some comments from another post into here, to keep discussions on-topic.

This is going to be the third fourth language advisory board then. We had the CFML Advisory Board (CAB), the intended Railo Technical Advisory Board (RTAB), The Iris spreadsheet for htmlX (Iris) and now the Lucee Language Advisory Board (LLAB?).

Who will be the one to judge who gets on this new advisory board membership? Is there a test or criteria that @agentK will be happy with?

I am sure @adam_cameron and @agentK are shoo ins as members, as is @seancorfield of course. Even though most of these people (I am not sure about @agentK) don’t do any CFML any more or are actively moving away from the language.

It’s a tough one.

1 Like

Yes, it is and I don’t claim to have a solution. As you surely have noticed I’m not saying LAS members can’t be on the board. All I’m saying is LAS member should not automatically qualify based on that fact.

Here’s a summary response on a few items you brought up.

a) It is tough - regardless of the number of previous “boards”. So I don’t think it’s relevant if there’s been 0 or 3 or 7 before. As you said yourself, they all fulfilled a different purpose.

b) There’s no certain criteria or particular skill set etc I could think of that qualifies some one for being a useful member. I think to come up with a “wishlist” or job description or “selection process” is part of the process we’re discussing here.

c) It’s not that I have to be happy with a/the criteria; the most important thing to me is that whatever happens, whoever is on that board and whoever makes the decision on who is on that board it all happens in the open and is transparent.

d) Just for the record, I write CFML pretty much every day, not necessarily 10h per day, but I use it. And just this fact certainly doesn’t qualify me to be on a board like this either.

If I was to come up with a list of “wanted” skills or interests for someone to join a board like the, I’d probably initially start with:

  • Needs to know and use CFML well
  • Needs to know other languages as well as other language paradigms at least reasonably well
  • Needs to have an opinion and is not solely a “yes man” person (sorry, I struggle to describe it better)
  • Needs to look beyond their personal interest (“I always wanted a tag or attribute for this and that because I have a use case”) and go for the architecturally better solution.
  • In a perfect world has done language design and specification work before

And I’m sure that other people have additional suggestions and I’m sure that people will disagree with my criteria.

From a selection process there are various options. You could go with the extreme basis democratic way like in Switzerland and have public voting of the Lucee mailing list members. You could go the other extreme and make it a closed door decision of LAS members. Both have obvious pros and cons and I think the reality will be that it’s gonna be something in between.

1 Like

Regarding the selection of members to the advisory board, from what I’ve seen of the suggestions that the Iris group developed, the great majority of them are not controversial, but rather straightforward, like merging the LS date and numeric functions with the non-LS equivalents. No need to make this more dramatic than it is.

I’m sure there will be points of disagreement, but the vast majority of improvements needed seem to be relatively obvious at this stage. Innovation will likely come not from pioneering work, but from borrowing concepts and practices from other languages where they already have been fleshed out and proved useful. So I see the work more as a responsibility taken on voluntarily that involves knowledge, experience and a willingness and ability to research rather than a position that needs to be carefully vetted. If someone is unable to contribute because of a lack of skill or experience, then it will become obvious rather quickly.


A bit further development … Perhaps my choice of wording in suggesting a “language advisory board” might not have been the best, and suggesting that this “board” makes decisions. I did not mean something like a supervisory board or a corporate board of directors that would “govern” LAS’s activities. To drop that connotation, it might be better to call it a “language advisory group”, or “language development team”.

This group of people already exists. They are doing research, looking at what is feasible, what can be prioritized, what might be interesting long term, etc. It is perfectly understandable that they don’t have time to write down everything they are discussing and share it with the rest of us, and open themselves up to even more discussion.

Then there are folks in the community that are very familiar with other languages. Maybe if a way was found to discuss ideas efficiently, they might help those in the existing group by contributing ideas, approaches to implementing them if they are good at Java, etc. I assume these people will find each other and quickly recognize their respective capabilities. I don’t see a problem with people drifting in and out of this core group, for instance participating only until the feature they are interested in, or highly competent at, is implemented.

The core idea I’m trying to communicate isn’t “governance” but a method for discussing language improvements efficiently in 2 tiers, core folks with some expertise, and the rest of us, using recorded Google Hangouts and an issue tracking app. Again, I trust that these people will find each other, and it’s perfectly fine, perhaps optimal, if the group isn’t static. Someone could be invited for one meeting only to present their idea for improving the underlying efficiency of the Java implementation, for instance.

In the end, the language advisory group decision remains a recommendation. Whether or not it gets implemented, and when, still comes down to the resources available to LAS, and how they decide to allocate them.

1 Like

For me, I think that diversity in any group is important. Clearly, there needs to be a presence of a variety of experiences - but I do not think that each member has to have all of the experiences (language design, use of CFML, etc. - indeed, it would probably even be useful to have someone on there with ZERO CFML experience).

More important than these things, I think members should be:

  • Able to listen
  • Able to work well together maturely
  • Able to show up to meetings frequently enough
1 Like