* Wish List Process

Please only post suggestions and requests for help on using this web site here.

For help with FAMILY HISTORIAN itself please post in the Using Family Historian - General Usage Forum above.
Post Reply
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

Wish List Process

Post by davidf »

Jane wrote: 04 May 2004 15:54 In due course, entries in [the New Wish List] Forum may either be

Transferred to The Wish List where you can vote on them.
Moved to another Forum , leaving a moved topic link.
Moved to the Closed Wish List Requests Forum.
Is there some form of criteria for deciding when something gets transferred to the actual wish list?

If I am reading the Wish list correctly it's over a year since any wish was added - and items used to get added fairly frequently:
  • 3 in July 21
  • 2 in May 21
  • 1 in April 21
  • 6 in March 21
  • 1 in 2020 (is this because Items on the List have been accepted or implemented?)
Is V7 so good that the level of requests has dropped, or have we become less good at succinctly specifying wish list items?

What might be the criteria as to what makes a "good" wish list item?
  • A clear statement of the user requirements
  • A clear statement of the benefits to users
  • A possible statement of the commercial benefit to Calico Pie
  • Some consensus (how?) that the requirement is:
    • Not already met (the requester has not found the feature; is there a replacement wish list requirement for greater clarity of how the feature is accessed or documented?)
    • Not met by means of some form of acceptable work around (but should the work around be incorporated into "main code"?)
    • Not wanted because the consensus (how?) is that the requirement is not good genealogical practice (does that create a documentation requirement?)
    • Not wanted because the consensus (how?) is that the requirement is likely to create a support nightmare?
  • Of a sensible scope - perhaps some wishes might usefully be split into an associated group of wishes?
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
ColeValleyGirl
Megastar
Posts: 5465
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Wish List Process

Post by ColeValleyGirl »

The process for stuff getting on the Wish List is that one of 2 people (currently) do the donkey work of transferring items when they have the time and when a request is 'good enough'.

Before that happens, we strongly encourage exploration of some of the things you mention, to validate that a new Wish is actually required -- the key part of which is: is the need already met either in the core product or a robust plugin? (We might conclude that something should be in core functionality, but a number of Wish List requests have been closed in the past because a robust plugin meets the need. Should they have been? I don't know....). Mike prefers that discussion to happen in the other forums; I'm not so bothered -- if the conclusion is the need is already met, we can move it at the end of the discussion if need be.

Documentation improvements don't go through the Wish List -- they should be requested from CP via support.

If the consensus is that a Wish List item is required, we strongly encourage the requestor to create a well-specified request, and we won't do anything until that is done -- either by the requestor or some other interested party.

I don't think we need to worry about the commercial benefit to CP, or the support implications -- that's their concern and I'm pretty sure they can handle that decision making process -- and we're not the Genealogy Practice Police (if something is really bad practice IMO I just put in my usual 'this must be optional and this is why' oar, for example, and if I really really hate it I give it a vote of 0 on the Wish List.)

But I suggest we need as a minimum:
  • a clear problem statement -- couched in terms of what isn't possible but is desired, and why
  • a statement of existing related Wish List items, and why they don't meet the need
What we don't need is an attempt to design a solution!

And when we move it to the Wish List, we might create one or more items referring to each other if it seems it can sensibly broken down (an elephant might be easier for CP to eat a bite at a time, to trot out a tired old maxim).

When faced with request for more detail, or to respond to suggestions, some requestors never bother -- so for example Autocompletion of source author (17785) has been languishing for over 1 year waiting for some more info, and I've just now moved it to Closed Wish List items.

I try to do a concentrated trawl of the items I've been involved in at least once a year; most of the ones you refer to in '21 were as a result of that. And '20 was a quiet year because we didn't do anything on the Wish List during beta testing of 7 for obvious reasons. I'm not sure how Mike operates.
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Wish List Process

Post by tatewise »

Part of the problem is that only a few FHUG users proactively provide solutions as opposed to asking questions.
That involves giving Advice, writing Plugins & Queries, updating the FHUG Knowledge Base, and Wish List to name a few.
None of them is getting any younger and some have more domestic diversions than previously.
I for one am finding my FHUG To Do List is growing faster than I can handle, partly due to increased functionality in FH V7 and I suspect partly due to more users switching to FH from other products and looking for solutions.
There have been some additions to the proactive team but we need more to satisfy the growing demand.
All offers are welcomed.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
ColeValleyGirl
Megastar
Posts: 5465
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Wish List Process

Post by ColeValleyGirl »

IIRC there used to be somebody who took the lead on the Wish List and pretty well only did that, in terms of proactive contribution. Or an I misremembering?
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Wish List Process

Post by tatewise »

I think your memory is correct, but that was many years ago, and if my memory is correct that person has not used their FHUG account for years, so I suspect may no longer be with us. That is my point about none of us getting any younger!
Anyway, some years ago extra people were granted write access to the Wish List, including me, so it became a joint exercise.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
ColeValleyGirl
Megastar
Posts: 5465
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Wish List Process

Post by ColeValleyGirl »

I was thinking it might be a self-contained task that somebody 'new' could volunteer for?
User avatar
NickWalker
Megastar
Posts: 2597
Joined: 02 Jan 2004 17:39
Family Historian: V7
Location: Lancashire, UK
Contact:

Re: Wish List Process

Post by NickWalker »

ColeValleyGirl wrote: 26 Jul 2022 11:03 I was thinking it might be a self-contained task that somebody 'new' could volunteer for?
Perhaps that's one for the wish-list! :)
Nick Walker
Ancestral Sources Developer

https://fhug.org.uk/kb/kb-article/ancestral-sources/
User avatar
ColeValleyGirl
Megastar
Posts: 5465
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Wish List Process

Post by ColeValleyGirl »

Or a 'Wanted' ad?
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

Re: Wish List Process

Post by davidf »

As the original poster I ought to respond to replies that I have elicited, but my apologies, I only found them a few days ago as my post (which was in reply to another) got shifted into this forum which until very recently I did not subscribe to - so no notifications.

The guts of the replies are in Helen's original post and I don't want to do a point by point reply but I think a few points may be made.

1. Moving posts. If the "New Wish List Request" is in the views of the mods something arising due to a user not understanding how the existing product (together with plug-ins) works, moving it to General Usage is I think appropriate and fair enough. There may be a certain number of posts first to clarify that that is the case - to avoid yo-yo'ing.

If, however, the post has a new requirement or a tweak to existing functionality and is moving towards a specification either of a wish list item for CP or a plug-in request for them or others to develop, perhaps it should stay in the New Wish List Request sub-forum (or be moved back into it) for two reasons:
  1. If maintains focus and ideas don't get lost in "General Usage". If matters don't progress they can be moved - as Helen does with Wish List items that stall for lack of user response - or they can be left to dwell in the back pages.
  2. Discussions of future enhancements or plug-ins may not be of prime interest to users of General Usage who are focused on "what can be done now". If they are interested they can subscribe to the New Wish List Request sub-forum.
With regard to requirements that might be met by new plug-ins, we are still talking about a "user need/user specification" process, so I think the New Wish List Request sub-forum is the bast place for initial discussions. Perhaps we have two wish lists to which requests may eventually go:
  • "The Wish List" (for CP to consider) and
  • "Plug-in Requests" for more complex plug-ins - distinct from the Sub-forum "Plug-in Discussions" which feels very LUA-specialist! Some plug-ins and some plug-in creators appears so fast this may not be required. Some times the plug-in may be a means of honing the requirements. "I want functionality like in plug-in X, but fully integrated into main code".
2. Items in the New Wish List Request sub-forum are there to be honed and clarified and tested - with suitable prodding. That is the purpose of the sub-forum?

3. Perhaps the labour involved can usefully be divided between the existing gatekeepers and the wider subscribers to the sub-forum - the latter prodding the requester to shape their request into a form that satisfies the gatekeepers. If that is the process, I doubt you need more gatekeepers - it's the prodders that are required. If this Sub-forum is active will they self-select - no "wanted ads" required? And also no worrying about creating another set of access rights?

4. In terms of criteria:
ColeValleyGirl wrote: 25 Jul 2022 18:33 But I suggest we need as a minimum:
  • a clear problem statement -- couched in terms of what isn't possible but is desired, and why
  • a statement of existing related Wish List items, and why they don't meet the need
What we don't need is an attempt to design a solution!
I think that probably covers the key issues - and possibly should be added to the "pinned post".

5. To help avoid repeat requests I think all request discussion should acquire a "disposition statement" from a mod or a wishlist gatekeeper when discussion seems to have plateaued which could be:
  1. Moved to General Usage for discussion as to how these requirements are currently met.
  2. Wish list Item XYZ created
  3. Deemed to be a program bug and ticket raised with CP
  4. Plug-in solution identified and either (i) created or (ii) put in the list of requested plug-ins
  5. [Temporary | Permanent] Work around defined and documented in KB (or added to the list on Maintaining The Knowledge Base)
  6. CP documentation issue and ticket raised with CP
  7. Other ...
I don't think we necessarily need to "close" a request. I don't see why for some requirements discussion may not continue or be reopened after a disposition statement but it is a means of taking stock and letting people know what has happened.

6. "Other" in the list above is because I think we do need to grapple with the hopefully only occasional "nonsense ideas".

For instance "Bad genealogical Practice" (?!) "I have a requirement for additional entry screens so that I can easily create a new family for each household for each census and link the 1891 household to the 1881 household by means of a child-parent relationship". (And please don't respond saying you think that is a "grand idea" - it's just an example!)

Or "Support nightmare" "I want to be able to directly edit the GEDCOM file from within FH just as I can edit a text note"

How do we "dispose" of such ideas - or do we just let them dwell in the back pages of the sub-forum like an unwanted orphan?
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
ColeValleyGirl
Megastar
Posts: 5465
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Wish List Process

Post by ColeValleyGirl »

I don't believe we should conflate the "New Wish List Request" process with requests or suggestions for plugins. The Wish List (which the the "New Wish List Request" process feeds into) is specifically aimed at providing Calico Pie with visibility of the enhancements we would like to see in the core product. It may be that a plugin can meet a need, either permanently or as an interim, but we should still make that need visible to Calico Pie with an indication of how popular it is via the voting process. They might already be working on something similar (in which case our input might help shape their thinking) or they might decide to build something into the core product even when a plugin exists.

If we siphon requirements off into a 'new plugin process' we'll hide them from CP, whereas keeping them in the Wish List process doesn't preclude a plugin author from taking the requirement and running with it. We have Plugins planned/in progress (19399) to ensure that plugin authors don't duplicate work unknowingly.

It's also my impression that the majority of plugin requests these days (more accurately, plugins developed in response to a request for help) are meeting a fairly niche need, so niche they tend not to end up in the plugin store. Do we really need a process for them?

Re gatekeepers, we may not need more, but we do need at least one with the time available to keep the 'Wish List' process ticking over -- the current gatekeepers do not.
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

Re: Wish List Process

Post by davidf »

ColeValleyGirl wrote: 23 Aug 2022 11:22 We have Plugins planned/in progress (19399) to ensure that plugin authors don't duplicate work unknowingly.
That Topic I have never spotted - mainly because plug-in development means learning a new "technology" (LUA) in addition to HTML, CSS, & Javascript which I learnt too long ago and Excel VBA which I learnt almost as long ago - so it is an area where I hesitate to go!

That Topic in "Plugin Discussions" - a forum which to non-plug-in developers has the implied warning "here be dragons - proceed at you own risk" (that Mozilla used to have when entering Firefox about:config) is consequently possibly invisible to many.

For non developers it is probably a useful topic just to be aware of what is being done and the sort of scope of things that can be done. Something else to subscribe to,
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
ColeValleyGirl
Megastar
Posts: 5465
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Wish List Process

Post by ColeValleyGirl »

That forum covers "Writing and using plugins for Version 5 and above." and includes error reporting and advice on using existing plugins -- it's definitely not just for developers.
Post Reply