Separation of Virtualisation / NAS Issues in Support Forum


Recommended Posts

I have noticed that the General Support sub forum is littered with VM related issues this year. Obviously it would be expected that this would increase given the release of v6 BUT it appears that users are not getting the msg that VM related issues should go in the "KVM Hypervisor" subforum.

 

This concerns me a little as all data related issues are naturally going to be posted to the General Support Sub Forum and those "should" IMHO be the focus of our support in the first instance. It concerns me that users will have data issues and with the sheer volume of additional VM related issues in the General Support sub forum some users will have their posts missed and not get as quick a response as they would normally get => which as we know could lead to them doing something which is ill advised that might result in data loss.

 

I was thinking perhaps there is scope for some more granularity. Perhaps:

 

General Support

Data Loss (Maybe Disk Failure) Support

Installation Support

Virtualisation Support

Docker Support

Plugin Support

 

I think given that the virtualisation sub forum is called "KVM Hypervisor" allot of users might not be clear that this is where the "Virtual Machine" type issues should go. My friend said to me the other day "I'd love to setup 2 Virtual Machines. What's KVM?"

 

Either way I am sure it won't stop people posting VM support issues in the General Support Sub Forum entirely BUT what I am suggesting "might" help us segregate the data loss related issues and help those who are at risk of loosing data and perhaps are in need of a quicker response than those just wanting to boot a Windows 10 VM.

 

For everyone's consideration. Just thinking out loud.

Link to comment

+1

 

I think this is a very good idea and much more logical than what we have now. I think someone at Limetech will have to make this happen since this is more than us ordinary mods have authorization for.

 

We could just leave the old threads where they are and only move active threads as we encounter them.

Link to comment

I too agree.  I've moved several VM threads that were not getting any attention, just so they would get more of the right eyeballs.  I suspect that with the increased traffic in General Support, more VM veterans are avoiding it, and staying in the VM sections more.

 

Some small changes to the forum descriptions might help.  Add a note to the General Support (V6) description, to indicate that all VM support inquiries should use the KVM Hypervisor board.

 

And I agree, the KVM board name could be changed.  Not everyone knows what KVM is or what a hypervisor is, even if they already have some VM experience.  VirtualBox and others make it too easy, and tend to hide some of the technical stuff.

 

I'm not sure about the best way to split up the support, other than the VM support.  It's good to start a discussion though.

Link to comment

+1.  The new virtualization features are bringing people to the unRAID platform who have primary interest in those features and may have limited interest in NAS storage capabilities.  That's great, but it's getting complicated to figure out how/where to get your support question answered.  In particular I think we risk loosing potential virtualization users if it isn't clear where the community of support is located...

 

I think the current forum layout is more structured around the engineering features of unRAID rather than the mindset of the occasional visitor who is looking for help.  For instance the primary Docker forum is the engine forum, and the sub-forum is container support.  But what does the average user want to do?  Probably get help with a container.  Similarly, virtualization topics are located in KVM Hypervisor, but all these new users don't seem aware that KVM is the underlying technology - they just want help getting their VMs up and running.

Link to comment

Fantastic idea and if we can do anything further to reduce the posts about various container support in the docker engine thread that would be good too.  Perhaps make the stickies bold or flashing or something...  ???

Maybe sparkly can make some nice sparkly icons  ;D

Link to comment

My initial votes for changes (just for the Support (unRAID 6 Only) section) ...

 

Child Boards have the disadvantage that their description is not visible, which may be part of our problem.  For example, 'Docker Containers' has a good description, but it is only viewable if you click on 'Docker Engine' first.  Some of the child boards also are just as important or more important than the top level boards.  I'd like to 'promote' several of them (the Docker and plugin child boards), but not 'VM Templates'.  If we want users to use certain boards for support, then it makes some sense to have those boards at the top level.

 

* Add an instructional note about VM, Docker, and plugin support to the General Support description

* Set the Docker Container board next

* Rename the 'Docker Engine' board to 'All other Docker support', and put it below the container board

* Rename 'KVM Hypervisor' to 'All VM support' and put it next

* Rename 'VM Template' to 'VM Archive', leave it as a child board, but move its only 2 active threads to the main VM board (stickied?)

* Rename '6.1 (Verified)' to 'Support for current V6 plugins', and set it next (top level), with an appropriate description

* Rename '6.0 (Unverified)' to 'Support for older V6 plugins', and set it next (top level), with an appropriate description

* Rename 'Plugins (V6)' to 'All other V6 plugin support', and set it next, with an appropriate description

 

With these changes, it might look like this -

 

General Support (V6)

  Help with setup, configuration, disk issues, and questions about unRAID.  Not for VM's, Dockers, or plugins, please use the appropriate board below.

 

Docker Container support

  For support using Docker containers in unRAID.

 

All other Docker support

  For all non-container issues with Docker service on unRAID.

 

All VM support

  For all support configuring your own virtual machines in unRAID, including device assignment and passthrough, and any other VM issues.

  VM Archive

      Older and inactive VM related threads.

 

Support for current V6 plugins

  For support of all plugins verified to be compatible with unRAID 6.1 or later.

 

Support for older V6 plugins

  For support of all V6 plugins not verified to work with unRAID 6.1.

 

All other V6 plugin support

  For plugin requests and other non-specific plugin discussion and questions.

 

I know there's interest in further breaking up the General Support board and the VM support board, but I'm not sure of what we gain there.  Certainly though, a Windows 10 VM board would be popular!

Link to comment

My initial votes for changes (just for the Support (unRAID 6 Only) section) ...

 

Child Boards have the disadvantage that their description is not visible, which may be part of our problem.  For example, 'Docker Containers' has a good description, but it is only viewable if you click on 'Docker Engine' first.  Some of the child boards also are just as important or more important than the top level boards.  I'd like to 'promote' several of them (the Docker and plugin child boards), but not 'VM Templates'.  If we want users to use certain boards for support, then it makes some sense to have those boards at the top level.

 

* Add an instructional note about VM, Docker, and plugin support to the General Support description

* Set the Docker Container board next

* Rename the 'Docker Engine' board to 'All other Docker support', and put it below the container board

* Rename 'KVM Hypervisor' to 'All VM support' and put it next

* Rename 'VM Template' to 'VM Archive', leave it as a child board, but move its only 2 active threads to the main VM board (stickied?)

* Rename '6.1 (Verified)' to 'Support for current V6 plugins', and set it next (top level), with an appropriate description

* Rename '6.0 (Unverified)' to 'Support for older V6 plugins', and set it next (top level), with an appropriate description

* Rename 'Plugins (V6)' to 'All other V6 plugin support', and set it next, with an appropriate description

 

With these changes, it might look like this -

 

General Support (V6)

  Help with setup, configuration, disk issues, and questions about unRAID.  Not for VM's, Dockers, or plugins, please use the appropriate board below.

 

Docker Container support

  For support using Docker containers in unRAID.

 

All other Docker support

  For all non-container issues with Docker service on unRAID.

 

All VM support

  For all support configuring your own virtual machines in unRAID, including device assignment and passthrough, and any other VM issues.

  VM Archive

      Older and inactive VM related threads.

 

Support for current V6 plugins

  For support of all plugins verified to be compatible with unRAID 6.1 or later.

 

Support for older V6 plugins

  For support of all V6 plugins not verified to work with unRAID 6.1.

 

All other V6 plugin support

  For plugin requests and other non-specific plugin discussion and questions.

 

I know there's interest in further breaking up the General Support board and the VM support board, but I'm not sure of what we gain there.  Certainly though, a Windows 10 VM board would be popular!

 

Great suggestions RobJ. I am an advocate for more granularity of the General Support forum though. Here is my suggestion and rationale:

 

General Support (V6)

  Help with setup, configuration and questions about unRAID.  Not for VM's, Dockers, or plugins, please use the appropriate board below.

 

Disks, storage and data support

    Help with disk configuration, migration, replacement, failures, rebuilds, filesystem corruption and loss of data related issues.

 

My rationale for the above section is that I consider Data and Disk related issues to be the MOST important type of issue that unRAID users can have. We make sub forums for Docker and VMs yet we ask users to post critical issues in a forum littered with posts about "arguably" less important issues (e.g. - based on the forum right now: build advice, how to find flash GUI ID, transfer speeds, Help setting up public key auth for ssh, Double folder won't stop!, Unraid behind a proxy, Mover running twice somehow?). First and foremost I consider unRAID a NAS device (although I don't want to start a discussion about that and its evolving nature) and data is the most important issue. Certainly with the introduction of 6.2 and dual Parity we are going to get an increase in these type of issues too (first rebuilds of due parity disks etc etc).

 

I also think there is room for a new section of the forum (But I think this will take some preparation and discussion before it is implemented) along the lines of the following:

 

I make the following suggestions because of what I see as huge failings in the management and long term sustainability and viability of the wiki as well as a lack of updated documentation generally from LT.

 

unRAID Manual

 

Suggestion: We could break the user manual up into a range of locked down stickies. We could even restrict the ability for users to post and have it a reference only sub forum. Without a doubt (as far as I am concerned anyway) the forum is the single source of truth for unRAID and it is the first stop for users in most cases. Jeez, users have stated that they have started using unRAID for the support of the community only. Therefore I feel it makes sense to break up the manual to have it easily referenced from the forum too. Plus (and this is the biggest selling point for me) the editing of the "forum manual" would be easier and faster.

 

EDIT: Example of issue with wiki: http://lime-technology.com/forum/index.php?topic=47082.0

 

How to Guides

 

Suggestion: There are so many people who come to the forum looking for quick how-to guides. These guides can span multiple dockers, plugins and config. Why not store these guides in one place. Its valuable information. We could lock it down the same as I mention above and only allow pre vetted guides to be published BUT the biggest difference between this and the Forum Manual is the Forum Manual will be based on official documentation and only supported uses of unRAID and strictly controlled. The How to Guides can be user submitted (albeit vetted to ensure compliance with forum rules) and cover almost any topic or use, officially supported or not.

 

For everyones consideration.

Link to comment

Disks, storage and data support

    Help with disk configuration, migration, replacement, failures, rebuilds, filesystem corruption and loss of data related issues.

 

My rationale for the above section is that I consider Data and Disk related issues to be the MOST important type of issue that unRAID users can have. We make sub forums for Docker and VMs yet we ask users to post critical issues in a forum littered with posts about "arguably" less important issues (e.g. - based on the forum right now: build advice, how to find flash GUI ID, transfer speeds, Help setting up public key auth for ssh, Double folder won't stop!, Unraid behind a proxy, Mover running twice somehow?). First and foremost I consider unRAID a NAS device (although I don't want to start a discussion about that and its evolving nature) and data is the most important issue. Certainly with the introduction of 6.2 and dual Parity we are going to get an increase in these type of issues too (first rebuilds of due parity disks etc etc).

It's a good idea, probably should be done.

 

I have to admit some reluctance though, whenever new boards and splitting up current boards are brought up.  Last time there was a forum reorganization, just 3 people (trurl, jonp, and myself) did all the thread movement to the new boards, and it was a lot of work, took a while.  You can't batch move them, you generally have to open each one up and read some of it, in order to make the right move decision.  Thread titles are often not much help.  And this looks like it could be a lot more threads to move than the last time.  But that doesn't mean it shouldn't be done.

 

I also think there is room for a new section of the forum (But I think this will take some preparation and discussion before it is implemented) along the lines of the following:

 

I make the following suggestions because of what I see as huge failings in the management and long term sustainability and viability of the wiki as well as a lack of updated documentation generally from LT.

 

unRAID Manual

 

Suggestion: We could break the user manual up into a range of locked down stickies. We could even restrict the ability for users to post and have it a reference only sub forum. Without a doubt (as far as I am concerned anyway) the forum is the single source of truth for unRAID and it is the first stop for users in most cases. Jeez, users have stated that they have started using unRAID for the support of the community only. Therefore I feel it makes sense to break up the manual to have it easily referenced from the forum too. Plus (and this is the biggest selling point for me) the editing of the "forum manual" would be easier and faster.

 

EDIT: Example of issue with wiki: http://lime-technology.com/forum/index.php?topic=47082.0

 

How to Guides

 

Suggestion: There are so many people who come to the forum looking for quick how-to guides. These guides can span multiple dockers, plugins and config. Why not store these guides in one place. Its valuable information. We could lock it down the same as I mention above and only allow pre vetted guides to be published BUT the biggest difference between this and the Forum Manual is the Forum Manual will be based on official documentation and only supported uses of unRAID and strictly controlled. The How to Guides can be user submitted (albeit vetted to ensure compliance with forum rules) and cover almost any topic or use, officially supported or not.

 

For everyones consideration.

Great ideas!  It will take a lot of work though, and needs volunteers.  LimeTech staff are very busy currently.

 

As to the current wiki, you are right, but I can't help sighing, thinking of all the work it needs.  And finding volunteers has been very hard.  (Anyone want to help?  ->  Start Contributing)  I don't want to depress any of the ideas, but from experience I do have to be realistic.

Link to comment

I have another thought to add to the mix. Perhaps the "General" ought to be at the bottom of the support section, so that maybe people might scan through the categories of Virtualization, Web GUI Add-ons, Dockers, Plugins, Hard Drive or SSD troubleshooting and whatever other main headings are there, and only land in General if they can't find a fit.

Link to comment

I have another thought to add to the mix. Perhaps the "General" ought to be at the bottom of the support section, so that maybe people might scan through the categories of Virtualization, Web GUI Add-ons, Dockers, Plugins, Hard Drive or SSD troubleshooting and whatever other main headings are there, and only land in General if they can't find a fit.

 

Good idea and perhaps renamed "Everything Else"  ;D

Link to comment

I have another thought to add to the mix. Perhaps the "General" ought to be at the bottom of the support section, so that maybe people might scan through the categories of Virtualization, Web GUI Add-ons, Dockers, Plugins, Hard Drive or SSD troubleshooting and whatever other main headings are there, and only land in General if they can't find a fit.

 

Good idea and perhaps renamed "Everything Else"  ;D

 

Personally I don't like "General Support" sub forums. By definition they tend to be able to be used for ALL areas of support (whether there is a sub forum for a specific area or issue or not) The term General is too widespread and things can get out of control.

 

My preference is definition. unRAID is not that complex that we shouldn't be able to specify the areas of support to render a "General" area superfluous. The benefit is of definition is in itself in the word - where to post your thread will be very clear.

Link to comment

Personally I don't like "General Support" sub forums. By definition they tend to be able to be used for ALL areas of support (whether there is a sub forum for a specific area or issue or not) The term General is too widespread and things can get out of control.

 

My preference is definition. unRAID is not that complex that we shouldn't be able to specify the areas of support to render a "General" area superfluous. The benefit is of definition is in itself in the word - where to post your thread will be very clear.

So here's your first test, a list of odd topics I found -  :D

What new board should each one go in?

 

* build advice

* how to find flash GUI ID

* transfer speeds

* Help setting up public key auth for ssh

* Double folder won't stop!

* Unraid behind a proxy

* Mover running twice somehow?

 

* File system and data integrity consensus

* Pushover Help

* How many pre clear cycles is enough?

* gfx card advise

* move existing disks to array?

* Dead Motherboard...

* USB PCIe Suggestion

* Troubleshoot possible Kernel Panic

* Losing connection to unRAID Server randomly

* How do I shrink my array?

* Marking clocksource 'tsc' as unstable...

* What is the current status of NVMe support?

* Need upgrade advice plz

* Moving media folders in Windows 10...

 

I'm sure I could find more, each unrelated to the others!  The core of unRAID may not be that complex, but as an OS it includes a lot of areas and features, and each release adds more.  Convince me we don't need a 'catch-all' board, and that brand new users would readily and always start in the correct board.  ;)

Link to comment

Convince me we don't need a 'catch-all' board, and that brand new users would readily and always start in the correct board.  ;)

 

I hear unraid 6.2 will fix that.  ;)

 

Why is it every time I see you've posted, I know pretty much exactly what you're going to say....  ::)

Link to comment

Personally I don't like "General Support" sub forums. By definition they tend to be able to be used for ALL areas of support (whether there is a sub forum for a specific area or issue or not) The term General is too widespread and things can get out of control.

 

My preference is definition. unRAID is not that complex that we shouldn't be able to specify the areas of support to render a "General" area superfluous. The benefit is of definition is in itself in the word - where to post your thread will be very clear.

So here's your first test, a list of odd topics I found -  :D

What new board should each one go in?

 

* build advice

* how to find flash GUI ID

* transfer speeds

* Help setting up public key auth for ssh

* Double folder won't stop!

* Unraid behind a proxy

* Mover running twice somehow?

 

* File system and data integrity consensus

* Pushover Help

* How many pre clear cycles is enough?

* gfx card advise

* move existing disks to array?

* Dead Motherboard...

* USB PCIe Suggestion

* Troubleshoot possible Kernel Panic

* Losing connection to unRAID Server randomly

* How do I shrink my array?

* Marking clocksource 'tsc' as unstable...

* What is the current status of NVMe support?

* Need upgrade advice plz

* Moving media folders in Windows 10...

 

I'm sure I could find more, each unrelated to the others!  The core of unRAID may not be that complex, but as an OS it includes a lot of areas and features, and each release adds more.  Convince me we don't need a 'catch-all' board, and that brand new users would readily and always start in the correct board.  ;)

 

I am actually already on it. I didn't want my post to be full of piss and wind so I grabbed an extract from this morning's (for me) posts and seeing if I can logically categorise them within the constraints of what I am proposing.

Link to comment

Personally I don't like "General Support" sub forums. By definition they tend to be able to be used for ALL areas of support (whether there is a sub forum for a specific area or issue or not) The term General is too widespread and things can get out of control.

 

My preference is definition. unRAID is not that complex that we shouldn't be able to specify the areas of support to render a "General" area superfluous. The benefit is of definition is in itself in the word - where to post your thread will be very clear.

So here's your first test, a list of odd topics I found -  :D

What new board should each one go in?

 

* build advice (1)

* how to find flash GUI ID (2)

* transfer speeds (3)

* Help setting up public key auth for ssh (4)

* Double folder won't stop! (5)

* Unraid behind a proxy (6)

* Mover running twice somehow? (7)

 

* File system and data integrity consensus (8)

* Pushover Help (9)

* How many pre clear cycles is enough? (10)

* gfx card advise (11)

* move existing disks to array? (12)

* Dead Motherboard... (13)

* USB PCIe Suggestion (14)

* Troubleshoot possible Kernel Panic (15)

* Losing connection to unRAID Server randomly (16)

* How do I shrink my array? (17)

* Marking clocksource 'tsc' as unstable... (18)

* What is the current status of NVMe support? (19)

* Need upgrade advice plz (20)

* Moving media folders in Windows 10... (21)

 

I'm sure I could find more, each unrelated to the others!  The core of unRAID may not be that complex, but as an OS it includes a lot of areas and features, and each release adds more.  Convince me we don't need a 'catch-all' board, and that brand new users would readily and always start in the correct board.  ;)

 

Righty. it's early Saturday afternoon, too early for a wine, weather sucks ... let's give this a whirl.

 

Firstly, I have decided to expand on my ideas for the forum. A bit radical BUT your task of putting posts into the right areas got me thinking. unRAID itself is broken into logical areas. Why not use them? So here is my stab:

 

P.S. I have numbered each of your points to reference where they would go in my suggested design.

 

 

Support

 

Welcome to unRAID Support - START HERE

- Learn how the forum works. Do’s and Don’ts, How to ask for support. Capturing Diagnostics and Logs.

Documentation

- unRaid Manual. How to Guides, Videos and more.

Installation (2, 10)

- Need help installing unRAID. Preparing your USB, Booting up, BIOS Configuration, Prepare your disks, Assigning devices to Array and Cache.

unRAID OS (3, 7, 15, 16)

- Need help with General Operation, GUI Freezes, System Instability and Performance, Parity Checking and Mover.

Disks, storage and data support (8, 12, 17)

    - Help with disk configuration, cache pools, migration, replacement, failures, rebuilds, filesystem corruption and loss of data related issues

Sharing (5, 21)

- Help with User Shares, Disk Shares, Do’s and Don’ts, Moving and Copying Files, Allocation Methods, Split Levels and Security

User Preferences

- Help with GUI customisation, Notifications, Display Settings and Scheduled Tasks

Network (6)

- Help with Network Issues, Bonding, Interface bridges and DNS Settings

Current Plugins

- For support of all plugins verified to be compatible with unRAID 6.1 or later.

 

Plugin Archive

- Older and inactive Plugin threads

App Support (9)

- The only place you need to go to get support for all vetted unRAID Community Applications

 

App Archive

- Older and inactive App threads

Virtual Machine Support

- For all support configuring your own virtual machines in unRAID, including device assignment and passthrough, and any other VM issues.

 

Virtual Machine Archive

- Older and inactive Virtual Machine threads

Docker

- Manual Container installation, Docker Development and other non Container related issues.

Advanced (4, 18)

- Not afraid of the command line. Like to do things with your unRAID machine that would scare the average user. Here is where you belong.

Virtualizing unRAID

- Running unRAID as a Guest under ESXi. Get your questions answered here.

 

Hardware

 

New Builds (1, 20)

-Propose your build, discuss Hardware for unRAID, considerations, compatibility, known issues and advice.

Motherboards (13)

- Which board has the most SATA ports. Server or Consumer grade. Discuss here.

CPU’s

- What CPU do you need? What is coming? What works well?

Disks

- Mechanical Drives, SSD’s, Hybrids. All round disk discussion.

Controller Cards (14)

- Need more SATA ports. Not sure what cards are compatible with your hardware. Compatibility issues. All discussed here.

PSU’s

- Scotty, I need more POWER! Whatever you choose your Server Needs Power. Make the right choice!

Graphics Cards (11)

- Adding Gaming capability to your server, need a graphics card for an HTPC. Not sure what to buy. Look here for help and discussion.

Build Examples and Compulsive Design Projects

-Starting a Project? Want to show off what you’re doing or what you’ve done? Post Photo’s, get advice. Here is the place.

 

Community

 

Lounge

- A place for new users to introduce themselves and existing users to have storage/technology-related discussions.

User Customisations

- Customizations and tweaks done by users (scripts, banners, etc). Not for discussing plugins.

Good Deals!

- Post references to good deals found on components. No buy/sell/trade in here please.

Buy, Sell, Trade

- Buy sell and trade your unRAID Hardware as long as you stick to the RULES.

Vendor Forums

Product support, feedback, questions, discussions, and other interaction directly with vendor representative(s).

 

**I Didn't place 21 in the above structure as I felt it was a feature request and should go where all feature requests go under the Development Section.

 

I think what I am proposing is self explanatory. As you can see I am proposing doing away with the General Support Forum in favour of a more defined functionally related breakdown of support areas.

 

I have also added 2 x reference areas (no user posts) in "Welcome to unRAID Support - START HERE & Documentation". to try and get users to read, give us an area to post support material (manuals, how to's, videos), ask for support, pull their diagnostics etc.

 

In my first post I suggested migrating the information that is in the wiki and all over the place into one area. Perhaps migrating is a little strong BUT I just don't think the wiki works. The power of unRAID support is in this forum. Even some of the older hats (IMHO) would be more likely to edit a support "Sticky" than go in and edit a Support Wiki Entry. It doesn't mean the same rules can't apply it just means we are making everything available in one place.

 

I am also suggesting something with respect to Docker (I know this might be controversial) BUT I think we will should adopt the name "App" when we talk about Containers. Community Applications (App Tab) already does this BUT the forum does not. I know Community Applications is not a LT product but I don't see how that really matters when what we want to do is drive the users into the correct area. They install Apps, allot of people now refer to them as App's (me included) - thanks Squid ;). Let them request support in an Apps area. "Docker" is used (in my suggestion) for the non container type stuff, development and so on (could even be expanded). Notice how I have kept the Docker section away from the main (general user support areas at the top) and stuck it down near the "advanced" sections at the bottom.

 

I am going to go on to say that I also think that the number of Build, Hardware related posts we have shows that "hiding" (thats how it feels to me) the Hardware Boards in the Community Section is not working. I think the forum needs to address Hardware better than it does now.

 

I decided to get carried away and just put my ENTIRE idea out there. From Support through Hardware to Community. I've left the "Company Area" and "Development Areas" alone as I don't think changing that helps the support of users in any way.

 

For your consideration.

Link to comment

+1 on that organization.  Although I'm sure the mods will hate it due to the amount of work involved in moving everything around, but it does make sense

 

I am also suggesting something with respect to Docker (I know this might be controversial) BUT I think we will should adopt the name "App" when we talk about Containers. Community Applications (App Tab) already does this BUT the forum does not. I know its not a LT product but I don't see how that really matters when what we want to do is drive the users into the correct area. They install Apps, allot of people now refer to them as App's (me included) - thanks Squid ;). Let them request support in an Apps area. "Docker" is used (in my suggestion) for the non container type stuff, development and so on (could even be expanded).

Actually, jonp was who got me onto referring to everything as an app when he kept on going on about how docker container / plugin / vm appliance are just different delivery methods for an application.
Link to comment

+1 on that organization.  Although I'm sure the mods will hate it due to the amount of work involved in moving everything around, but it does make sense

 

I am also suggesting something with respect to Docker (I know this might be controversial) BUT I think we will should adopt the name "App" when we talk about Containers. Community Applications (App Tab) already does this BUT the forum does not. I know its not a LT product but I don't see how that really matters when what we want to do is drive the users into the correct area. They install Apps, allot of people now refer to them as App's (me included) - thanks Squid ;). Let them request support in an Apps area. "Docker" is used (in my suggestion) for the non container type stuff, development and so on (could even be expanded).

Actually, jonp was who got me onto referring to everything as an app when he kept on going on about how docker container / plugin / vm appliance are just different delivery methods for an application.

 

Well I really like the App term for unRAID. It is a non technical term for an area which can be very technical and complex and using it almost will drive (IMHO) those users (who are not comfortable in the technical aspects) into the App area and stay away from terms like "Docker" when they have a nice friendly, familiar word like "App" to focus on.

 

I know the Mod's might hate it, but we are a community. I am sure there are ways to get others involved (without making an army of Mod's) to take the load of them. For me its simple cost benefit. Is it worth the effort for the benefit we will get out of doing it. Let's see what people think. This is very much preliminary design .....

 

:)8)

Link to comment

I'm still up for a forum where only the container support threads are found.  And make it clear that if you want support for a particular container then post in that thread.  Helps us monitor the relevant threads and archives the information for others to read.  Then have a sub-forum for any other docker issues.

 

And personally, getting all militant about it, if you don't post in the support thread, it gets ignored +/- deleted..  ;D

Link to comment

I'm still up for a forum where only the container support threads are found.  And make it clear that if you want support for a particular container then post in that thread.  Helps us monitor the relevant threads and archives the information for others to read.  Then have a sub-forum for any other docker issues.

 

And personally, getting all militant about it, if you don't post in the support thread, it gets ignored +/- deleted..  ;D

 

In a way isn't that what I am proposing though....

 

 

App Support (9)

      - The only place you need to go to get support for all vetted unRAID Community Applications

 

      App Archive

        - Older and inactive App threads

 

Docker

      - Manual Container installation, Docker Development and other non Container related issues.

 

 

To address your post specifically:

 

- If you want help with a "container" then it goes in "App Support" under the appropriate thread (no user thread creation allowed)

- All other "Docker" support does in "Docker" (apply whatever permissions to that thread you want. I'd suggest none as it is aimed at the more "advanced" users).

 

We can be "Militant" about it still AND having this sort of definition in the forum allows us to do that. E.g.:

 

> I am a user who wants help with one of the Plex App's.

> I scan the Forum

> No General Support so I have to Choose

> I see the App board (and because I refer these to App's and Dockers it makes it easier). No board's seem to have ANYTHING to do with App's so I open it.

> I try and post a general help me with Plex thread. I can't because it is locked.

> In realising that the board is locked (because I am a dumb user who didn't read the sticky about how the board works) I look for the appropriate Plex thread.

> I find it.

> I post my support query.

 

Just making suggestions here. Happy for as much input and critique as possible. I want to generate traction as the more I think about this the more I think this is going to be a change for the better.

Link to comment

I really wanted to respond before now, and I don't have time right now either, life is interfering, for a few more days, but here's a few points -

 

* Really a worthy effort, you put a lot of work and thought into it, and I can agree with most of it.

 

* But I think quite a bit of it is too ambitious.  It's a proposal to meet an ideal, the way 'it ought to be', but doesn't take into account the way 'it is'.  Some of the changes can be phased, helping to spread the work load out.  And perhaps some of it will need to be scaled back, due to the labor realities, the limitations of using volunteers, and the limitations of LimeTech being a very small and almost understaffed company for this.

 

* The *huge* elephant in the room is what to do with the current boards, and all the current threads in them.  We're not working in a vacuum here, the implementation HAS to include what happens with each board, and how their threads are split up among which new boards.

 

* I really don't want to be the spoil sport here, but I just felt that the current reality was not presented, incorporated into the plan.  And that's a big enough problem that it HAS to be an important part of the design.

 

* While I like the terminology change to call them Apps, there MUST MUST MUST be the word 'container' clearly noted, in very obvious places.  Most users are going to be looking for 'container support' and nothing else!  'Container' HAS to be at least as prominent as 'App'.

 

* Splitting up boards into more granular ones, can be a good thing in some ways, but only to a point.  It also has significant downsides.

  - Some boards have multiple topics, but those topics have considerable overlap.  For example, the current "Motherboards and CPUs" board would be split into "Motherboards" and "CPU’s", but it's hard to talk about CPUs without discussing CPU slots on motherboards, and which are compatible.  And it's hard to talk about motherboards without talking about which CPU's would work.  If that board is split up, then you'll have a lot of CPU discussion in the Motherboards board, and a lot of motherboard discussion in the CPU's board.

  - Users find it confusing when there are too many boards for what they want to post about.  "My post is partly about both, should I post here, or should I post there?"  The fewer the boards, the less the confusion, because like it or not, users like catch-all boards.  They know they can't make a mistake then.

  - And some posters will avoid posting at all, if there's any confusion.  We underestimate the barriers to posting for some users, who after bad experiences elsewhere, are absolutely certain they don't want to make a mistake here, and post in the wrong place.

  - And last, a big one, someone has to examine and move many of the current threads to which ever new board seems more appropriate.

 

* There always is a catch-all board, one that users will use when they can't figure out where else to post.  You can't define for everything.  Right now, I suspect 'unRAID OS' will become the one, partly because it says unRAID!

 

* There's currently one builds board, but it looks like you would like to make 2 builds boards?  How would you split the current threads up?  I could be wrong, but right now, the descriptions for both look essentially the same (although worded very differently).  How would you make it clear to users which one to use?

 

* If it's not clear by now, I think I would prefer to leave many of the current Community boards as they are.  ;)  The Support boards are more amenable to splitting/movement, but that workload again ...  I suspect both trurl and I may leave town for awhile, on a LONG sabbatical, when some of the changes begin to be implemented. :D

 

* When you said "I Didn't place 21 in the above structure", I think you meant 19?

 

* Many of your question placements seem right to me, but some could easily go in multiple places, as users do not all think alike.  A user will be sure of their choice, but a moderator will be just as sure of a different choice.  This is definitely going to result in more thread movement, ongoing.  The more choices, the more will be wrong.

 

I don't want to take anything away from your work, lots of great ideas there.  I can't take much time right now for further discussion though.

Link to comment

 

* While I like the terminology change to call them Apps, there MUST MUST MUST be the word 'container' clearly noted, in very obvious places.  Most users are going to be looking for 'container support' and nothing else!  'Container' HAS to be at least as prominent as 'App'.

 

Have to disagree here.  Most users (especially new ones) have no idea what a container is, but know exactly what an app is (nor do they care what the delivery method is)

 

Perhaps a simple solution is to get rid of Docker Engine and Plugins sub forums, and toss them both as is into a new subforum called "Apps".  (Could be wrong here, but I think that can be done easily by an administrator with mods not needing to move any threads around)

Link to comment

 

* While I like the terminology change to call them Apps, there MUST MUST MUST be the word 'container' clearly noted, in very obvious places.  Most users are going to be looking for 'container support' and nothing else!  'Container' HAS to be at least as prominent as 'App'.

 

Have to disagree here.  Most users (especially new ones) have no idea what a container is, but know exactly what an app is (nor do they care what the delivery method is)

And I could be wrong.  But we're talking here about users seeking support for their app/container?  How would they have gotten this far without having had to read a fair bit about Dockers and containers?  They should be 'inDOCtrinated' by now, more likely to say 'container' than 'app'.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.