stashapp / stashdb-docs Goto Github PK

There's been a few requests for better guidance on how to source info for JAV scenes and performers, including what is acceptable for a scene's studio link (also covered by issue #27). This would essentially be an expanded version of what Kouaak wrote up a while back, the most recent version of that is currently hosted here:
https://pb.envs.net/?4b5fda28e6ff1fff#4QFTViBmU69ALys7qbpZY8BAQxApqWs78Cn2vhrJ87Lb

In addition to JAV performer resources covered in Kouaak's pastebin, we could also cover:

• Studio links for scenes, mentioned in the issue linked above
• List of common studio websites and guidance on how to navigate them to find the appropriate scene link
• Other 3rd party resources for scene metadata

We should use Kouaak's guide as a starting point, so please comment with any specific additions or corrections you would like covered in the guidelines. I'm also not sure yet if it would be best to create a standalone "guide" page collecting all this information or if it would be more appropriate to put each subject in the relevant "getting started" sections instead.

We haven't had a clear consensus on how we want to format tattoos and piercings for performers. We need to decide:

1. If we want to standardize our "locations" somehow. And if so, to what? (I know Echo has some ideas on how to do this.)
2. Do we want to standardize capitalization? Specifically, capitalize the first word of just the location, first word of location and description, every word of location and description, or no caps at all?

I'm pretty sure the most common method right now is simply to copy-paste phrases from IAFD or FreeOnes into the right fields unchanged.

Needs official approval:
https://guidelines.stashdb.org/docs/performers/performer-images/#hardcore-performer-images

We should be able to approve this one as-is.

Needs official approval:
https://guidelines.stashdb.org/docs/performers/performer-images/#performer-image-size

Haven't seen any pushback to the language in this one. Main thing here is deciding if we should enforce a minimum image size when other photos are available and what that size would be. Images are already removed for being too small, we just don't have a hard line saying when that is or isn't appropriate.

We had a proposal for officially standardizing our capitalization of tag names and aliases recently, which was approved in this Discord thread. We've already been using standard title casing for individual words and all caps with no punctuation for acronyms on the vast majority of our names and aliases, so this is essentially just a formal approval of our current approach.

We don't really need a separate issue for this topic because it's already been discussed and approved elsewhere. I'm mostly just writing this issue to test out a new workflow relating to issue #1 about tracking changes to the guidelines. And to prove that I am working on this and haven't forgotten about the recently approved thread.

Needs official approval:
https://guidelines.stashdb.org/docs/scenes/scene-performers/#ambiguous-scene-performers

We should be able to approve this one as-is.

While I don't believe we should require contributors to vote a certain way, we could still add more guidance in our docs on how we expect contributors to use their YES and NO votes. Topics would include when to feel confident in a YES vote, common courtesies like explaining NO votes with a comment, when/how to ping someone on Discord, when to slow down a vote with a NO, when to reject it outright, and when to abstain from voting at all.

Again, these would be considered "suggestions based on current conventions" rather than "rules that must be followed" since so many votes will depend on the individual edit, voter, and submitter. Creating a strict rubric for voting instead would run counter to the current democratic system we have in place for approving all edits. Essentially, they should explain what voters should consider before deciding to vote YES or NO rather than saying explicitly "X = YES" and "Y = NO", if that makes sense.

We would also likely need a warning that abusing the voting system may result in an admin revoking your edit/vote rights, along with a description of what we would consider abuse.

The "Voting on StashDB" section is getting a bit long and unwieldy already so we may have to split it up somehow. I may experiment with multiple levels of headings for these "Getting Started" pages since so many are essentially miniature guides for each topic. Most of them already split into paragraphs to separate sub-topics so it shouldn't be too difficult to add appropriate sub-headings to describe them.

Current section: https://guidelines.stashdb.org/docs/getting-started-stashdb/#voting-on-stashdb

This discussion started on the Stash Discord in #stashdb-general (originally by Norse and later me; Fishtrack), and i am now posting it here to attempt to get to a resolution.

The issue is whether performers gender on StashDB should be listed as either what the performer identifies as and prefers being called. Or whether they should be listed as the general identity they go by in their work.

This problem currently leads to performers gender being switched around every few weeks, which in turn creates confusion. A good current example of this is Lulu Chu , who's gender was first set to female then changed to non-binary (what she identifies as) and then shortly after changed back to female.

I understand that what people identify as may be a sensitive subject for some people but it is important we reach a agreement, so we can atleast reduce the amount of needles gender changes on StashDB.

To be completely clear this issue relates to ALL performers and isn't exclusive to a single case like Lulu Chu.

Feel free to expand on the issue or say what you think.

Needs official approval:
https://guidelines.stashdb.org/docs/scenes/adding-scenes/#pornhub-scenes

We should be able to approve this one as-is. But I think I misspelled "PornHub" throughout the whole section (should be "Pornhub"?)

Needs official approval:
https://guidelines.stashdb.org/docs/tags/creating-tags/#new-tag-requirements

This section explains the rationale I've used for deciding if a new tag addition is appropriate, whether the tag would be helpful enough to be worth adding at all. It acknowledges that these determinations are subjective but that subjectivity is unavoidable when managing tags.

What this section does not cover is whether certain fields need to be filled out for a new tag request to be approved. Meaning, do we require a description and/or category for all new tags? And should that requirement be coded into Stash-Box/StashDB somehow? There was a discussion not too long ago about at least requiring a description for new tags. Personally, nearly any description would be enough for me. Just something to explain what the intended usage for the tag is, specific language and formatting can always be updated later. And if I'm the one doing the updating, it's always easier for me to "correct" an existing description than it is to come up with a completely new one by myself. I feel like this should probably be covered in a separate section of the guidelines though, so it may be appropriate to make a new issue covering these kinds of questions.

There was a recent discussion on Discord about whether certain scenes should be allowed on StashDB as "re-releases." Our current definition in the relevant section is simply "same network releases again" with no further elaboration.

When I originally wrote that definition, I was thinking of networks like BangBros and TeamSkeet who have both taken existing scenes and released them a second time under a new sub-studio to fill it out with more scenes early on. I haven't double-checked, but I remember these re-releases having new URLs, titles, and release dates.

The new examples that were brought up included PervCity and Nubiles-Porn. These networks would have the same scene listed under the sub-studio as well as the network with unique URLs. However, there was no other unique info between the two locations. I feel like these examples aren't truly released by two different studios but simply listed in two different locations. I believe they should be considered duplicates that should not be added to StashDB at this time.

I can write up revised language clarifying the difference between a "re-release" and a "re-listing" in a new PR. Before merging however, I'd like to know whether this change will be considered significant enough to require a new thread submitted for approval or if the previous thread will be enough to cover it.

While thinking about the best way to organize the request detailed in issue #28, I'm wondering if we could better organize our "Getting Started" sections. This is essentially a braindump of an idea I had 2 minutes ago so bear with me.

So in Stash-Docs, we have a heading in the sidebar to collect Beginner Guides including our often recommended Guide to Scraping. Organizing it this way allows us to point at a single location for anyone looking to get started with Stash for the first time, explaining any important concepts/features that may not be immediately obvious within the application's UI. A lot of our "Getting Started" sections for StashDB function the same way, but the formatting there mirrors the "user manual" approach to each individual section of the actual guidelines that need "official" approval. This makes some pages more cluttered than they need to be and fragments some others. I can see it confusing the overall formatting of the site to new contributors.

I'm thinking a similar setup to the "Beginner Guides" in Stash-Docs may be better. We can collect all the "Getting Started" sections from the various headings to de-clutter those sections a bit, clearly separate "guides" from "guidelines" (the rulebook sections essentially), and allow for more flexibility in their formatting (i.e., more pages patterned after the step-by-step approach used in the Guide to Scraping). We could have a "Guide to Performers/Scenes/Studios/Tags" made up of the various "Getting Started" sections currently under their respective headings. We could also add new stand-alone pages for "Guide to Joining", "Guide to Contributing", "Guide to JAV", and whatever else we think could be useful.

Moving all these sections around would also likely break a lot of internal links, so we'd have to be thorough with a project like this. For anyone reading, let me know if you think this would be a more intuitive way to organize these topics. Either way, I've never been totally happy with the way everything's organized since a lot of those decisions were made due to the limits of the original GitHub wiki it was hosted on. We've got a lot more flexibility with the new Jekyll-based system and I don't think we've taken full advantage of the differences yet, so suggestions on that front are always welcome.

With the advent of technology like PimEyes or some adult wiki sites that link to a performer's personal social media (defined here as social media accounts that are unrelated to their adult work), we should consider mitigating the uploading of any non-adult work related images for reasons related to doxing.

Consider adding the following clause to acceptable images, "All images must be related to the performer's adult work or adult work persona. Images unrelated to their adult work are not acceptable"

• Adult work examples
  • Images or screenshots derived from adult studio work ✅
  • Images of the performer in their adult persona, such as at an adult convention or on a public red carpet event ✅
• Non-adult work related images example
  • Mugshots ❌
  • Images from their personal social media accounts where the account has nothing to do with their adult work ❌

On this page https://guidelines.stashdb.org/docs/performers/edit/performer-images/ consider adding the following:

Performer images serve to identify a performer and to document any changes to their appearance over the span of their career, including stylistic and physical transformations.

I would suggest adding the above excerpt above the note and below the main heading since it describes the general purpose of performer images.

Describing a general purpose for images may help reduce -- or at least give voters some foundation for voting on -- the submission of irrelevant photos such as images of well known performer's wearing masks or having their faces otherwise obstructed from being identified. It also shows the intent of images on StashDB are along the lines of fair use, to document a performer's looks only, and not just to include any image that people find aesthetically pleasing.

Consider also outright mentioning in the appropriate section that images of masked performers (excluding performers who exclusively ONLY wear masks) are undesirable.

Needs official approval:
https://guidelines.stashdb.org/docs/studios/adding-studios/#animated-studios

It was decided early on to limit animated scenes to only "professional studios" and not "independent creators." This keeps it in line with how we handle other scene-types that are predominantly fan-made like compilations and PMVs. The description explains that this was a decision intended to "move slowly" with this content, expecting that opening ourselves up to content on digital marketplaces, Patreon subscriptions, etc. would be too difficult to manage in the early stages of the StashDB project. We also don't allow more traditional scenes/movies hosted on digital marketplaces and Patreon subscriptions either, so this is still in line with the broader consensus regarding those platforms as well.

Also, this policy is currently only explained here under the "Studios" section. I feel like it needs to also be explained under "Scenes" as well since it addresses what kinds of scenes are currently eligible to add onto StashDB.

Occasionally, studios will use an animated image (GIF or WEBP) as a scene cover. I believe BangBros will do this for some scenes. Though Infinite has previously stated that he isn't concerned with the increase in size for animated images, the general consensus has been to replace them with static equivalents instead. This is mostly for a desire for consistency across StashDB, though size and bandwidth could be a concern for any users pulling a lot of these images into Stash.

Users have also discovered that animated images are already supported in Stash for both performers and tags. StashDB does not host any tag images at this time, but I believe the same desire to avoid animated images for scene covers should apply to performers as well. We will need to add new guideline sections clarifying this stance for both scenes and performers.

Also worth noting that I don't believe we would need to restrict animated images for any of these objects if we were able to save multiple images and label them accordingly. I laid out some options in this old RFC for performer image categories. We could include "animated" as an option in addition to the others mentioned there like crop, pose, state of dress, etc. I imagine a similar system for scene covers could work as well, supporting multiple images labelled appropriately like "official", "custom", "3rd party", "scene cover", "thumbnail", "screenshot", and of course "animated." I can't find an existing issue for alternate scene covers in the Stash-Box repo yet, but I can add one.

Needs official approval:
https://guidelines.stashdb.org/docs/performers/performer-images/#performer-aspect-ratio

I don't believe there's much controversy on 2:3 as the preferred ratio here, but instead we'll need to consider how rigid or lenient we'll want to be in enforcing it. The current phrasing is, "There is no hard requirement for enforcing this ratio at this time."

Needs official approval:
https://guidelines.stashdb.org/docs/studios/adding-studios/#classic-studios

Closely related to issue #34 and shares the same reasoning behind that guideline. Ultimately, the consensus has been to wait for new features to better handle alternate releases and to bundle together full movies with their split scenes before committing to these kinds of studios/scenes.

Needs official approval:
https://guidelines.stashdb.org/docs/scenes/scene-descriptions/#preferred-scene-descriptions

Most of this is pretty straightforward and very similar to issue #25 and closely related to issue #33. It boils down to us preferring the original official studio description over modified descriptions. It also says that we'd rather have an empty description field instead of unofficial descriptions or placeholder/boilerplate descriptions.

Just like "Preferred Scene Titles", it also does not mention any exceptions to the guideline, even though the section immediately below lists all of the relevant exceptions. We should probably include something like, "See the next section for possible exceptions."

Also just like scene titles, a new feature allowing for alternate descriptions in Stash-Box could help with some of these issues and points of confusion.

Needs official approval:
https://guidelines.stashdb.org/docs/tags/merging-tags/#merging-sorted-tags

This is another rule of thumb I came up with on my own back in the Google Doc days for the guidelines. Essentially, it's an extension of my definition of "sorted" tags explained in the Getting Started page.

I could probably soften the language of this section, but the point is that tag merges should be more closely examined if it removes a tag that's already been defined by another contributor. This likely means that a determination was previously made that it should remain separate from other existing tags and that this decision shouldn't be overruled without serious consideration.

Needs official approval:
https://guidelines.stashdb.org/docs/scenes/scene-performers/#missing-scene-performers

This one gets pushback from newer contributors, but it doesn't actually say, "Downvote any scenes missing listed male performers." It says they "should be included" if they're listed and that finding missing names from external sources (IAFD, etc.) is "greatly encouraged, but often not required." I don't expect the core of the language to be modified here but there will likely be suggestions to strengthen or weaken the guideline's recommendations on how to enforce it.

We need to add new sections providing guidance on the studio codes field. Unofficial/unapproved should be fine at first for this, there seems to be a pretty solid consensus for how we've been using it already.

This will likely need to include specific examples for how we handle network/studio X, Y, and Z. We've gotten a few questions on Discord already about that, "Where do I find the studio code for this particular site? Is it the number in the URL or something else?"

Needs official approval:
https://guidelines.stashdb.org/docs/tags/assigning-tags/#priority-sources-for-tags

I came up with this priority ranking on my own for the Google Doc guidelines way back when, but it's always seemed pretty straightforward to me. Essentially, it places the full video as the primary source that trumps anything else that may be used for adding/changing tags. It also requests that edits explain what source they are using when editing a scene's tags so other voters/contributors will know whose source should take precedence in case there's some conflict.

Needs official approval:
https://guidelines.stashdb.org/docs/scenes/movies-dvds/#full-dvd-entries

Currently, we only have this section to explain how we handle full movies but we don't clarify our stance on DVD/movie scenes anywhere else. This should be covered in a separate section, but the two should still link/refer to each other in their descriptions.

Needs official approval:
https://guidelines.stashdb.org/docs/performers/performer-names-and-aliases/#eligible-performer-aliases

Needs official approval:
https://guidelines.stashdb.org/docs/scenes/scene-dates/#preferred-scene-dates

There are many who would prefer we track the closest available date to the day of filming in order for Stash to calculate the most accurate age as possible for the performers in the scene. This is essentially the Date of Production which is sometimes officially listed in production cards or on the back of DVDs. We've been holding off on using production dates until we can add them as a separate field from release date. I believe tracking both dates is necessary to properly handle multiple releases moving forward, so preserving the actual release dates as much as possible will be important.

Needs official approval:
https://guidelines.stashdb.org/docs/scenes/scene-descriptions/#correcting-scene-descriptions

This one's very similar to issue #26 and closely related to issue #32. Essentially it says that original official descriptions should not be corrected for simple errors in spelling, punctuation, etc. but that technical glitches like encoding errors, visible HTML tags, white space and line break issues, etc. can still be fixed. The assumption here is that these errors are introduced by bugs in old scrapes or migrations and do not represent the "original official descriptions" mentioned in "Preferred Scene Descriptions".

Needs official approval:
https://guidelines.stashdb.org/docs/scenes/scene-titles/#correcting-scene-titles

The reasoning behind this one isn't immediately obvious and so it also isn't a particularly well-known guideline. The idea here is that it is harder to find the scene elsewhere if the title has been "corrected" in some way. Consideration is also made for the addition of alternate titles so that scenes can track both original unaltered titles in addition to titles "corrected" according to an agreed-upon style guide for StashDB. Speaking of, we would also obviously need to agree on what that style guide should be before we would even know what kinds of corrections we'd want to make.

One exception we currently include here is adding scene numbers to the end of the title. We may want to decide on a shared formatting for this as well for the sake of consistency.

Discussed on Discord starting here, we have an example of a long scene split up into multiple parts by the studio that all share the same "shoot ID". Obviously we'd want to save the shoot ID as the studio code in StashDB, but what's less clear is if we need to differentiate the codes between each part somehow.

For now, I think we can just use the same studio code for each part since Stash-Box doesn't require them to be unique. I'm not sure if we need to or will want to make them unique either. I know JAV movies are regularly identified using studio codes but I don't know if there's any widely used system for split scenes within JAV. If we decide it's something we should do, we'd want some standardized system (something like adding _1, _01 or even - 1 would be enough) and I figure we'd need to approve something in #stashdb-guidelines before implementing anything like that. I wouldn't put anything "unofficial" into the guidelines other than "leave them the same, unaltered from the studio" until then.

We need to better clarify what is and isn't acceptable for the "studio link" field for scenes. In particular, there are concerns about using JAVLibrary links in this field instead of original studio websites. We could also use this section to explain guidance around public links vs. members-only links, semi-official affiliate links, network vs. sub-studio domains, and "canonical" link structure (including a www., MindGeek slugs, etc.)

(Related to this topic is similar guidance around performer links — what constitutes an "official website" in particular — and a request for better guidance on how to source pictures and performer/scene info for JAV.)

This is a situation where we have already formed a shared consensus around best practices, so we should be able to add "unofficial" sections covering this subject without waiting for "official" approval first.

We could use some clarification in Correcting Scene Titles and/or Preferred Scene Titles regarding the existence of studio-specific conventions we have developed over time. Most of these studio-specific title conventions function as an extension to the existing language for appending something like - Scene 2 at the end of a title when appropriate. Even though we prefer unaltered "original official" titles from the studio, we allow exceptions for differentiating ambiguous titles from within a studio.

For example, repeat appearances on Jesse Loads Monster Facials almost always share the exact same scene title since they just use the performer's name. This is complicated by the fact that JLMF's public website is difficult to navigate, with users required to find and manually copy most scene information from the homepage instead of the dedicated scene page that only includes a scene title and trailer. Since the title slug of the studio link includes a number for repeat appearances, we've taken to renaming these scenes to follow the pattern Performer Name 2, Performer Name 3, etc. to help differentiate scenes that can be very easily confused for each other.

Discussion on Discord has also pointed out a few different examples of gay studios that do not have a single clear, unique title on their website. At least one of these studios uses multiple variations of the title displayed in different areas around the website: one on the scene page, another on the performer page, a third above the comment section, etc. This requires contributors to agree which variation should be considered the "official" title for consistency on StashDB.

Studio-specific conventions are unavoidable for other fields too. Sometimes scene covers and studio codes can be ambiguous as well, requiring a decision to be made on how the guidelines should be interpreted for a particular studio. A similar problem develops with studios who are known for changing scene titles, covers, dates, descriptions, etc. over time as well. While we have more specific guidelines to address these conflicts, it would still be helpful to be able to point out to contributors which studios have a known track record of changing particular fields.

For example, Tonight's Girlfriend replaced all of its scene covers a few years ago, prompting many contributors to attempt replacing "incorrect" images on StashDB after running a fresh scrape. On the other side, sister-network Naughty America didn't have clear "original official" titles for most of its existence (and the closest equivalents aren't helpful as unique identifiers) so its titles exist in a unique situation where fresh scrapes are allowed to replace older titles since the older titles aren't "original official" titles either. But that's difficult to communicate to new users with less experience handling these studios on StashDB.

It would likely be too difficult to maintain a list of studio-specific conventions within the guidelines website, but it would be helpful to have some resource to point to for new users. Perhaps we could add a page describing what we mean when we say "studio-specific conventions", explain how they're expected to be followed just like other unconfirmed guidelines, and maybe link to an issue in this repo dedicated to tracking these conventions. An issue should be much easier to update and maintain compared to the Jekyll docs. Echo6ix has also suggested a couple different options for tracking discussions and conventions within StashDB requiring new features developed for stash-box:

stashapp/stash-box#574
stashapp/stash-box#700

Needs official approval:
https://guidelines.stashdb.org/docs/performers/performer-names-and-aliases/#preferred-performer-names

This one will take more consideration. Right now the language is essentially, "We don't have any kind of standard, but consider these factors when deciding what you think works best." I believe we would benefit from having clearer guidance on what we prefer for a performer's primary name but I'm not sure what approach we would prefer here since it's such a subjective topic. That's why the current section doesn't commit to anything in particular right now. The only way to do this may be to rank them in order of priority and explain when it's appropriate to move down the list to the next highest priority when deciding on a name.

Factors to consider (let me know if I'm missing any):

• Unique names (best to avoid single names like "Lola" or "Tony", but what if that's definitely the most famous/common alias?)
• Most frequently used alias (Indexxx the only external source for this, but method isn't completely reliable)
• Most famous/popular alias (how would this be determined?)
• Most commonly used as primary name by other databases like IAFD
• Alias currently/recently preferred by the performer (often not the most famous/recognizable name)
• Famous usernames on amateur platforms like OnlyFans, Pornhub, etc. (looks inconsistent if it's not really a "name")

As Stash/Stash-Box gets better at handling disambiguations, it should become less important for the primary name to be unique. But until then, that factor is often going to be at odds with many of the others on this list.

It has already been well-established that single-name performers like Jane or John need to have some disambiguation attached, even if there are no other performers currently known to share that name on StashDB or elsewhere. However, we don't have anything in the guidelines to clarify this yet.

I expect that this will be a quick and easy addition. I also expect that we'd be able to approve the unofficial language (as described above) without much pushback or alteration.

From this thread on Discord, we should probably update the language in our section on Creating Amateur Studios.

1. There's confusion around how we want to handle pro-am content from RFC. We can mention them specifically within the section and clarify the difference between 1st party content produced by RFC themselves and the 3rd party pro-am content hosted on their RFC channels platform.
2. RFC Channels uses odd language to describe their age verification processes, but they appear to still require 2257 documentation from all of their creators. We may want to update the language to clarify that pro-am platforms are required to be "2257 compliant"
3. We may want to just create two bulleted lists of "approved platforms" and "disallowed platforms"
4. On first glance, this section looks a bit too dense and wordy. It could be better organized, breaking up some of these blocks of text. The lists in point 3 could help with that, or alternatively we could split some of this up into multiple pages.

I have one particular subject in mind for this topic, but if we're going to move a bunch of things around we might as well collect all our concerns here under a more generalized subject-line. Hopefully if we get a good idea of what changes we want made, ideally we'll only have to move everything once.

One thing I've found inconvenient about the current organization of our guideline pages is that so many sub-headings aren't exposed to the sidebar. The only way to navigate to, for example, our "Amateur Studio" section is to click on "Adding Studios" in the sidebar and then click "Amateur Studios" in the auto-generated table of contents. And that's only if I already know which heading it's under. Otherwise I'd have to browse through the higher-level "Studios" heading first or try to use the search bar at the top.

I wasn't sure before, but it looks like it is possible to have multiple nested levels in the sidebar. For example, just-the-docs (our Jekyll theme) has this page nested three levels down. This wasn't possible in the simple GitHub wiki we started with, so the new site just inherited that "everything on one page" approach.

It'll be a pain to rearrange everything, but I think it would look cleaner and be easier to navigate if each section had its own page so everything can be listed in the sidebar. This will take a while to accomplish too so I'd like to have some agreement on the best approach for a project like this first before we commit to anything. Again, share any other ideas in this thread as well. It should be easier to tackle everything at once instead of changing everything around several times over.

It's been pointed out on Discord that we have a recurring image quality issues pertaining to AI upscaled images. Because image submissions appear as small thumbnails, the quality of an image is difficult to determine. Hundreds from the user in question have already been approved, and there could be more from other users that have evaded detection.

I propose we take this opportunity to revise the image guidelines to explicitly add a section on image quality that aims to give users an understanding of what constitutes good and bad image quality, including examples of forbidden images.

Image Quality

The objective of the StashDB image repository is to document a variety of a performer's looks throughout their career. We [should] aim to achieve this while maintaining clearly defined standards of quality images.

Good Quality

An optimal image should meet the following criteria when viewed at full size:

• Sharp, clear, and free from visual artifacts
• Image looks "natural" with no obvious third-party image modifications
• Moderate to large resolution

Remember that bigger is not always better. Submitting a smaller image with superior clarity and sharpness is preferred over a larger, blurrier one with artifacts at full size.

Low Quality

Identify low-quality images through the following indicators:

• Very small resolution
• Noticeable artifacts, such as blockiness, jagged edges, pixelation, strange color patterns
• Blurriness or out of focus
• Inappropriate aspect ratio {link to the 2:3 guidelines here?}
• Obvious signs of editing, including filters, effects, excessive saturation, excessive sharpening, over upscaling, and other modifications

No AI Upscaled Images

We strictly prohibit the submission of AI upscaled images. While AI upscaling can enhance clarity when used with proficiency, submitted upscales have lacked consistency and polluted the repository with low quality images. Some algorithms like CodeFormer, may provide visually appealing images, but distort the integrity of original facial attributes when used inappropriately.

No Altered or Modified Images; Prefer Originals

Avoid submitting edited images. This includes but is not limited to altering colors, tones, contrast, backgrounds, "Photoshopping", or introducing generative AI elements. We prefer non-edited original images to maintain consistency in quality.

Exemptions for Specific Scenarios:

1. Obscure performers often lack quality images. We accept their low-quality images when nothing else is available.
2. Cropped images at a 2:3 aspect ratio are exempt from our no editing guideline.
3. Images modified to exclude another performer's face or "hardcore act" are allowed if no better/higher quality images are available.
4. Edited image submissions are allowed from vetted contributors who have demonstrated a proficiency at their contributions, and with the express written consent from StashDB administrators only.

We've had a few questions recently about adding 3rd party DVD/movie scenes to StashDB. Our stance on full DVDs that only have 3rd party sources like IAFD or digital marketplaces (Adult Empire, Hot Movies, Bang!, etc.) is pretty well established but I don't believe we have anything on the books regarding split scenes relying solely on those same sources.

Unofficial consensus has been the same as full movies: we want a first party digital source as the "studio link" to use as our primary source of info. Basically, if it's coming from Studio X then we want everything to come from StudioX.com and if StudioX.com doesn't exist then it isn't eligible to be added just yet.

As it stands I feel like we have a substantial enough unofficial consensus to add the above clarification to the guidelines, but we'll still want to run it by everyone for "official" approval as well. And of course we also want to know if it turns out we'd actually want to go in a different direction with this.

In an act of ensuring information is not silo'd and that ground rules are always known, I think it would be useful to incorporate some sort of page that mimics a newsfeed/blog/changelog. This would contain all of the important changes that were made/voted on to StashDB guidelines and fundamentals via the Discord channel.

Posts/entries could include a structure such as:

• Timestamp of changes
• Quick summary of old methodology/guidelines/practices
• The new or adjustment of said above ^
• Why the change
• How to move forward/transition from said changes
• Links to deeper documentation of said change

From Discord, there was some discussion surrounding edge cases for how we want our scene titles formatted. Specifically, there's some confusion around situations where the title as displayed on the website (via CSS) uses different casing compared to the title grabbed from the scraper (via page source or API).

The working consensus has been to defer to the formatting grabbed by the scraper. This is my preference as well, since the internal formatting is much more likely to stay static through multiple website redesigns, strengthening its case as the "original official title" we're looking for.

I would mostly update the unconfirmed guideline for Correcting Scene Titles, but we could also use a clarification that some exceptions exist in Preferred Scene Titles while linking back to that same page.

Needs official approval:
https://guidelines.stashdb.org/docs/scenes/scene-titles/#preferred-scene-titles

This one does not mention any exceptions to the guideline, even though the section immediately below lists all of the relevant exceptions. We should probably include something like, "See the next section for possible exceptions."

Also, this one was written following the prevailing consensus that original data is more valuable on StashDB than current data. The reasoning here is that original data is unchanging but can be hard to find while current data is a moving target but is usually easy to re-scrape.

Needs official approval:
https://guidelines.stashdb.org/docs/performers/performer-images/#multi-performer-images

We should be able to approve this one as-is.

Needs official approval:
https://guidelines.stashdb.org/docs/scenes/adding-scenes/#duplicate-scenes

We should be able to approve this one as-is.

We've never landed on a clear consensus regarding disambiguated performer aliases, for example: Jane (Studio). I know we have many of these in the database already, likely from scraping/copying from databases like IAFD that use this formatting. There have been recent conversations about expanding performer aliases to include this studio-based disambiguation as a built-in feature. Adding the studio in parentheses within the text isn't always known and would be a temporary measure unless/until a similar feature is added to StashDB instead. Confusion over how we handle these kinds of aliases pops up occasionally so we'll need to decide what our approach should be in the meantime.

Needs official approval:
https://guidelines.stashdb.org/docs/tags/creating-tags/#check-for-duplicate-tags

Pretty straightforward, just explains that tags may be rejected if they're too similar to existing tags. That's also touched on in the section immediately above it, "New Tag Requirements." It also explains that exact duplicates in names/aliases will fail even if they're not rejected by the voters.

We should be able to approve this one as-is, maybe add a link back to "New Tag Requirements" if anything.

The most glaring omission in the docs right now is the absence of any guidance for performer disambiguations. I punted on writing up an unofficial section at first because there didn't seem to be much of a consensus yet on how we wanted to format them, so it just says TBD here.

There is now an unofficial guideline section, but it will still need to be approved and revised. This issue has been updated accordingly.
https://guidelines.stashdb.org/docs/performers/edit/disambiguation/disambiguation-formatting/

We had a productive discussion started by Valmox with this Discord thread. Consensus there was leaning towards YYYY, Studio for disambiguations but it wasn't unanimous. There were a few competing suggestions in there as well. We may want to run an approval thread with multiple options to choose from instead of a typical Approve/Reject.