Document requirements for FoundationApp requests #70

Closed
opened 2026-02-20 11:15:07 -05:00 by deekerman · 7 comments
Owner

Originally created by @nomandera on GitHub (Feb 16, 2018).

To remove dev workload I suggest we document in the wiki the information requirements for a new FoundationApp requests. It is not expected that users will get this right all the time but it will present a barrier to carpet bomb requests and should ultimately kickstart a cimmunity effort to support this.

e.g. something like

  • homepage
  • xx char summary of application function
  • license
  • art assets

This would also spin of the requirement to define the technical and artistic criteria for the main image e.g. dimension, format, resolutions etc

Originally created by @nomandera on GitHub (Feb 16, 2018). To remove dev workload I suggest we document in the wiki the information requirements for a new FoundationApp requests. It is not expected that users will get this right all the time but it will present a barrier to carpet bomb requests and should ultimately kickstart a cimmunity effort to support this. e.g. something like - homepage - xx char summary of application function - license - art assets This would also spin of the requirement to define the technical and artistic criteria for the main image e.g. dimension, format, resolutions etc
Author
Owner

@nomandera commented on GitHub (Feb 16, 2018):

I have attempted an example to get started https://github.com/linuxserver/Heimdall/issues/94

This was easy to compile other than there are some unknowns with logo:

  • acceptable formats
  • acceptable dimensions (driven by format e.g. svg may not need resized)
  • github tickets are not flexible places to paste images due to limitaions in what is allowed
  • it may be better to have two logo fields, one being the source so that we can trace copyright and attribution and the other being the manipulated one

As per Slack we are going to run into issues where upstream projects artwork fall below an acceptable quality level for Heimdall. We also should avoid fanart style alteration that alter either colours, shape or combine upstream logo due to personal preference. Alternations like this should be made at the user level and FoundationApps should honour the design of the donor projects.

If this is not viable we should consider allowing the user to choose from more than one icon at install time and deafult to the offical one.

@nomandera commented on GitHub (Feb 16, 2018): I have attempted an example to get started https://github.com/linuxserver/Heimdall/issues/94 This was easy to compile other than there are some unknowns with logo: - acceptable formats - acceptable dimensions (driven by format e.g. svg may not need resized) - github tickets are not flexible places to paste images due to limitaions in what is allowed - it may be better to have two logo fields, one being the source so that we can trace copyright and attribution and the other being the manipulated one As per Slack we are going to run into issues where upstream projects artwork fall below an acceptable quality level for Heimdall. We also should avoid `fanart` style alteration that alter either colours, shape or combine upstream logo due to personal preference. Alternations like this should be made at the user level and FoundationApps should honour the design of the donor projects. If this is not viable we should consider allowing the user to choose from more than one icon at install time and deafult to the offical one.
Author
Owner

@Attoy commented on GitHub (Feb 16, 2018):

@anoma I totally agree with your suggestion but please forgive me if this is a stupid question. For example if a project uses MIT License, is the related artwork under MIT License too? Can we freely use the project's artwork?

@Attoy commented on GitHub (Feb 16, 2018): @anoma I totally agree with your suggestion but please forgive me if this is a stupid question. For example if a project uses MIT License, is the related artwork under MIT License too? Can we freely use the project's artwork?
Author
Owner

@nomandera commented on GitHub (Feb 21, 2018):

This is quite a complex question and the answer is usually "no". Most of the code licenses are not natrural partners to anything else (artwork, wiki etc) and it is one reason why in my example I link back to the original art. By doing so we preserve attribution and should upstream decide to care they can easily find that we have used the artwork and contact us.

Normally people would refer to this as "fair usage" but this is a very American concept that technically doesnt work globally however the moral ground this law stands on is the same ground we stand on.

I plan to document as simply as possible in the wiki what info I think is needed and we can discuss here any changes needed

@nomandera commented on GitHub (Feb 21, 2018): This is quite a complex question and the answer is usually "no". Most of the code licenses are not natrural partners to anything else (artwork, wiki etc) and it is one reason why in my example I link back to the original art. By doing so we preserve attribution and should upstream decide to care they can easily find that we have used the artwork and contact us. Normally people would refer to this as "fair usage" but this is a very American concept that technically doesnt work globally however the moral ground this law stands on is the same ground we stand on. I plan to document as simply as possible in the wiki what info I think is needed and we can discuss here any changes needed
Author
Owner

@MindTooth commented on GitHub (Jun 9, 2018):

I would also advocate for some some "standards" defining styles given for EnchancedApps. The current situation is a bit author-based, and is different across apps.

Currently using SABnzbd, Tautulli & Transmission, and between them they all have three different styles — though SAB and Taut shares some style. Now also a third/fourth stye is incoming – which I do deem cool. I have not checked others app on how the format there integration.

E.g.
screen shot 2018-06-09 at 09 54 59

PR for Deluge:
deluge_integration

@MindTooth commented on GitHub (Jun 9, 2018): I would also advocate for some some "standards" defining styles given for EnchancedApps. The current situation is a bit author-based, and is different across apps. Currently using SABnzbd, Tautulli & Transmission, and between them they all have three different styles — though SAB and Taut shares some style. Now also a [third/fourth](https://github.com/linuxserver/Heimdall/pull/201) stye is incoming – which I do deem cool. I have not checked others app on how the format there integration. E.g. <img width="1284" alt="screen shot 2018-06-09 at 09 54 59" src="https://user-images.githubusercontent.com/33870508/41189266-593bc606-6bcb-11e8-8357-f0343c715421.png"> PR for Deluge: <img alt="deluge_integration" src="https://user-images.githubusercontent.com/5650363/41178459-dff4009a-6b2c-11e8-8237-47253a5d55c5.PNG">
Author
Owner

@KodeStar commented on GitHub (Jun 13, 2018):

Yeah, it's getting a bit messy

@KodeStar commented on GitHub (Jun 13, 2018): Yeah, it's getting a bit messy
Author
Owner

@MindTooth commented on GitHub (Jun 21, 2018):

Somewhere to show small screengrabs of the enhancements would make sense too. In the wiki or a dedicated page (docs/applications.md).

@MindTooth commented on GitHub (Jun 21, 2018): Somewhere to show small screengrabs of the enhancements would make sense too. In the wiki or a dedicated page (`docs/applications.md`).
Author
Owner

@KodeStar commented on GitHub (Oct 30, 2018):

App requests need to be made on https://apps.heimdall.site/ now.

@KodeStar commented on GitHub (Oct 30, 2018): App requests need to be made on https://apps.heimdall.site/ now.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/Heimdall-linuxserver#70
No description provided.