• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Forum, Wiki, Twitter, Blog...?

It would be interesting to know the reason, if any, for the chosen name. Where does 'affinity' come from, or does it just have a good ring to it?

Also, I'm not sure that the five items you propose are all necessary. 1) and 2) are essentially the same thing and IMO 3) and 4) do not need separate formalised names.

I would suggest that only 3 terms are needed: the overall project name, a term for the firmware+webif components and a term for the optional items. To take your example, that would give something like:
- Affinity
- the Affinity Core
- Affinity Components
 
I thought of Affinity because the word encapsulates a synergistic relationship (I could make up some waffle about Affine Transformations but that would be stretching things).

I disagree with what you say about combining 1 & 2, 3 & 4.

Installing Affinity:

Step 1 - download the (?), extract the .zip and copy it to a FAT32 UPD.
 
I don't see a problem in writing instructions for upgrades using two different methods.

I don't think your premise about how to propose a terminology should stand. Specifically, the 5-point proposal format is too restrictive: it ties all suggestions to your initial concept. Also, it should be possible to combine a well-chosen project name from one set of suggestions (like 'Affinity') with a structure/component proposal from one or more different sets (like 'Project - Core - Components'). I think the discussion should be more free-ranging, at least in the initial stages.
 
Also, it should be possible to combine a well-chosen project name from one set of suggestions (like 'Affinity') with a structure/component proposal from one or more different sets (like 'Project - Core - Components'). I think the discussion should be more free-ranging, at least in the initial stages.

I agree with that, which is what I alluded to when I suggested we might discuss the components again. I really don't see how we can get away from the distinction between firmware and software, however we choose to name them, so we might just as well call them firmware and software in an effort to educate. My 5 divisions might be artificial and might go a different way, but if nothing else they provide an agenda.

Whatever, I've had my say, I'm going to butt out and remain schtum. When we have some more ideas on the table I propose we then draw up a short-list by everyone seconding a proposal - but not their own.
 
As the major contributor to the WiKi (but certainly NOT the owner), I feel I have a right to reply to the comments made in #7 of this thread, I feel the WiKi is a concise description of Humax features That is not bloated by the ego of the owner who feels obliged to plaster his name over every page.

If anybody feels the WiKi needs changing they can leave a comment to get it changed or change it themselves, I have no objection to either, Although I would object to people changing pages just to ‘Make their Mark’. Unlike threads the WiKi is not ‘locked’ to a single user and his particular ‘presentation skills’

As for the Title of the Custom Firmware Package I have no objection to it being changed, Although this has been decided once, To almost everyone’s agreement by the owner of the package, af123, If he wants to change it fine, It’s not for others to decide
 
I don't think deciding that "Modified" (I didn't choose it in the first place, only used it) is inappropriate constitutes deciding on a name, so no it has not been decided at all.
 
I'm very aware of, and very grateful for the amazing efforts that af123, Ezra Pound, drutt and others have put into this project, and quite embarrassed to stick in an unwanted oar by suggesting that things could be done in any way differently. It's a fine line between offering to help and interfering. In my mind these improvements belong to the people who created them and it's very presumptive of me and others to do anything that smacks of 'taking over'. Nevertheless, if I can assist, I'd like to do so.

I don't think this thing really started out as a 'project' at all - initially it was just a couple of people tinkering to overcome some of the Humax's most obvious foibles and failings. Over the months, it's become a real project as its complexity has grown and once the need for documentation became clear, documenters joined in and did a pretty good job, all things considered. It's not easy, outside a proper business environment, to establish standards and create a serious 'product' rather than a set of hobbiest routines, especially when nobody's getting paid for their efforts! Now, of course, the documentation 'belongs' to the documenters who took it on in the same way as the code belongs to the original coders and again, butting in is an uncomfortable business.

One thing I did learn in my years managing a technical publications department is that coders rarely want to get too involved in documentation. No aspersions cast - it's just a different sort of activity that requires different skills and appeals to different personalities. So perhaps our BYTs are not actually too unhappy that someone else is prepared to write the instructions.

I've also been a little surprised (given that the Fox series is now getting a little long in the tooth) how many new users have been appearing in these forums recently. In some cases, they've come in with quite basic questions, in others with quite advanced and specific enquiries. The body of documentation almost certainly includes answers to the basic questions but - for whatever reason - the posters seem to have difficulty finding them, to BH's exasperation... The more advanced issues are undocumented and, given the enthusiasm of the coding experts, often produce a flurry of activity that would probably be regarded as uneconomic in a business environment.

I'm inclined to agree with BH's suggestion that a pdf document containing all the basic operations of the enhanced system would be useful to a lot of people. The wiki is what the wiki should be - as EP says - and contains more items, but in less detail, than a pdf manual. The plethora of helpful but unstructured posts scattered around these forums - some of which I'm responsible for - are useful only to people who manage to find them and are uneditable by anyone except the original author. Sometimes they are duplicated and give conflicting advice.

Finally (you'll be glad to know), I'd like to ask if anyone has any idea just how big the Humax mods user base actually is. Documentation effort really needs to take some account of the size of the potential audience.
 
I know I said I would keep quiet while others had a chance to say their piece, but there seems to be input required.

I've been on both sides of the divide - an engineer and a technical author, so I have a good perspective and while it didn't bother me much as an engineer (never the highest priority) unless I had to read somebody else's documentation, as a tech author I've seen all the problems. I agree with Fenlander except for one point - I don't see why the Wiki shouldn't be authoritative, definitive, clear, and well presented - in fact the primary source. A pdf manual would capture the information from the Wiki in print for easy reference, and the layout of the Wiki could make that capture easy. Naturally, a pdf would be out of date the moment it was issued, so it will have to go through regular up-issues so the process MUST be easy.

For those who think "custom software" is an adequate name, suppose there is somebody else out there writing another custom software. How do we distinguish ours from theirs? It's not a name, it's a description, and we call our dog Rover to distinguish it from next door's dog called Patch. There seems to be a notable apathy of suggestions.

I know Fenlander will take it in the spirit of debate that is intended if I comment that just having "Core" (which I quite like) to denote everything except the optional packages would lead me to documentation containing phrases like "Affinity Core (firmware component)" and "Affinity Core (software component)". When considering the structure under the brand name we will have to consider how it will be used and what parts need identifying, and to some extent the choice of brand name will be influenced by its compatibility with the structure under it. I say the five points I mentioned before stand, but we can come back to the structure debate when we have some ideas for the overall brand.

Consider how you would rewrite the QUICK START GUIDE if you were using a proposed brand and structure. It's as short as I could reasonably make it to cover the key points, without being terse, and would make a good test of your concept.

Come on, let's get some ideas however off-the-wall.
 
There may be some merit in suggesting that Custom Firmware is a description and not a name, But my point and I think to some extent Fenlander’s also, Is that you wouldn’t want me to tell you that from now on your dog’s name is Rex. There is really only one owner of this project and that is af123, O.K. there have been other contributors but where would they stand without af123’s efforts?. In my view people shouldn’t have an equal say in what happens to this package however many times they post the same message
 
While I agree that its really up to af123 if the project were to be given a "name", i also feel that a "name" is not really required.

"Custom Firmware" does the job for me, it explains that it is customised, and that it is firmware that i must load on the box in the same way as the regular firmware. Regardless of the technicalities that it might not be actual firmware. Its by-the-by and over-thinking the situation.

With a slightly technical project such as this, there will always be issues with new users that are not tech savvy.
Calling something by a different name will not help or resolve that.
 
"Custom Firmware" does the job for me

The argument (not mine I might add) is, What happens if another Custom Firmware Package comes along? Without a name, it will get confusing. I think we have to be realistic, It's very unlikely another package will come alone and if it did that would be the time to distinguish between them. It really is a case of 'If it 'aint broke, Don't fix it' to me
 
If another firmware package did appear, i'm pretty sure the author would be aware of the potential for confusion and come up with a solution.
 
Finally (you'll be glad to know), I'd like to ask if anyone has any idea just how big the Humax mods user base actually is. Documentation effort really needs to take some account of the size of the potential audience.

There are almost 400 devices registered with the RS portal and firmware version 1.17 has been downloaded over 1000 times.
 
Taking the typical engineering approach to naming the project, a dictionary search like this http://www.onelook.com/?w=h*d*r*t&ls=a has chucked out some interesting options:

HackeDapaRT - self explanatory
HaDRian - A cool sounding name from history
HammeRheaD - cool, a project named after a shark
HanDcaRT - the SR71 blackbird was codenamed Oxcart, so why not
HarDReseT - Might get confusing
HarDcoRe - I think this would bad as far as search engines go

There's a lot in there, so maybe some others would like to have a browse and make some suggestions.
 
Play on words?

MaxHatch

Or, does it really need a 'special' name?

HomeBrew is sufficient? Everybody knows what homebrew is and of course it is Humax related.
 
I've been thinking about this, as you may have guessed, and I'm actually happy with the status quo. Customised firmware, software packages - say what you see.

Having said that, I'm not set against people discussing names and suggesting them, especially if that helps the documentation process.

Over on the Foxsat forums they have "Raydon's Media & File Server Bundle for the Foxsat HDR"* - not any better really!
(* I don't think Raydon uses his name as the prefix, other people have adopted it.)
 
Back
Top