Add contributing guide. #234
Conversation
|
I think some additional (even if it's just informally set out in the comments here) context around storyline aspects would be good. I can understand not wanting to include things for storyline roleplaying that is playing out solely on the MOULa shard, but how stringent do we want to be about things like Ages that include journals? Are we opposed to any additions to storyline? |
|
Thanks for writing this up - it will definitely be helpful to have the purpose, goals, and criteria for this repo stated explicitly. Meta question: what's the context and "approval state" for these guidelines? Is this a proposal from Hoikas, or have other H'uru folks already given some input, or are you writing down already existing informal guidelines? Have you (non-specific "you") already decided that the repo will be operated this way, or is this open for feedback/discussion to some extent? I have more thoughts on this, which I'll write down when it's not late at night for me. |
That's a good point. I was thinking that we would reject things that don't make sense in terms of canon (eg the original Serene journal submission) or involve roleplaying on a specific shard. Those Kirel messages mention characters that are RP'd on MOULa only, hence their rejection. Beyond that, I think that characters that exist in an Age (eg in journals, notes, etc.) are fine even if they are also RP'd.
Good question! This is currently a proposal from me on how this repository should be operated, and feedback is welcome. |
|
Outsider's perspective: I understand the need for this; however I find the proposed way this would be retroactively applied to prior content and open PRs a bit too extreme. Specifically: I think there needs to be more clarity as to what "no endorsement" means on a case by case basis - in other words, there needs to be a clearer distinction between something that was reviewed & actively non-endorsed (rejected) vs something that simply wasn't reviewed yet and thus lacks an endorsement - I don't think it's fair to equate the latter to a formal "rejection" when it may very well meet the guidelines despite not yet having an endorsement. Furthermore, what are we saying constitutes an "endorsement?" I feel that fully closing those PRs would be to communicate not even entertaining the possibility that these could ever be accepted, rather than simply marking them as "changes requested," "review requested," etc and indicating a potential attainable path to acceptance. I do not see why something like #145 or #75, which I feel follows these guidelines, should be rejected and closed; nor something like #52 which is still in development and very much falls within the guidelines, just because they lack a 3rd-party endorsement at this time. Perhaps I have misunderstood and you are merely using existing content & PRs as an example of how these rules would be applied, but I still feel that distinction between "not endorsed yet & will require an endorsement to be accepted" vs "actively non-endorsed & therefore rejected" is important to make. |
|
That makes sense. When I was writing my post, I had the two terms The major goal here is to reduce the amount of untested, experimental, unfinished, and/or inappropriate submissions. I'm hoping the new guide makes it a bit clearer what's appropriate and what isn't. For the sake of the discussion, I'm going to conflate subjective content with new Ages because they're easier to talk about. PRs for new Ages are not zero cost, unfortunately. There are two main costs, both of which are non-obvious to non-maintainers. They are cognitive complexity and disk space (potential monetary costs). Every time a pull request is opened, there is a new entry on the pull request page. I seem to be the one who is primarily handling PRs on this repository - this isn't problematic, but I have difficulty juggling more than a handful of active pull requests at any one particular moment. I am also responsible for a lot of other things, such as PRs to Plasma, improving Korman, keeping an eye on microsoft/vcpkg, and add RL on top of that. So, I really shouldn't be the one on the hook, so to speak, to do the baseline evaluation of new Ages. The baseline evaluation being things like fit with the rest of the game, lighting, etc. These are tasks that there are plenty of other people can do aside from just me, and I would like to see them involved in the process. There are a lot of people who DM me on discord and ask for me to review Ages to try to pump the brakes on them because they don't think the Age belongs in the game. There is similar discussion in IRC but with less prompting for me to do something. I think that if we can move more from a "someone needs to say no to this" mindset to a "someone needs to say yes to this" mindset will help alleviate both my workload and the concerns of the individuals who come to me. Ideally, this will slow the rate of submissions here to a more sustainable rate for me but also ensure that those items that do get submitted here can be incorporated more quickly. Ideally, I would be looking at just the technical merits here. The nuts-and-bolts of the creative isn't something that I think we need to be doing here. Additionally, every revision of an Age that's pushed to this repository consumes disk space. GitHub charges exorbitant rates for LFS data and bandwidth, so all of the data is actually hosted on guildofwriters.org. At this time, we are not close to consuming all of the disk space; however, I am cognizant that the space on guildofwriters.org is finite, and I would prefer to not have to pay for more disk space because this repository was used for pushing an unbounded amount of back-and-forth creative revisions. That's not to say that we don't want changes pushed here, but I would prefer to limit the commits to this repository to meaningful milestones. That being said, I'm going to edit the OP to change the |
It would be nice if there were some effect of people saying no to things, rather than stuff getting accepted and shipped off to MOULa regardless, but that's not really in the scope of this repository. Beyond to say that, there are things that are currently live on MOULa that were objected to on technical grounds, and those objections were ignored and as such that content will definitely not pass the technical review required to be included here. The lack of any actual approval process for content complicates both the reviewing of things, and the managing of this repository. Yet there is seemingly reluctance to implement any sort of general approval process for MOULa despite these concerns being raised multiple times. |
|
And that's the problem. I'm not delusional enough to think that I can dictate what policy MOULa uses, the hope is that if we can change the process here, we can at least be a model for what should happen going forward. Unfortunately, we can't put the genie back in the bottle on some of the things that have gone to MOULa. |
|
This is a topic that goes way way back. It's been sidestepped, ignored, and a general hot-potato for well over a decade. Yet it has to be hashed over, yet again, because every past discussion has faded into oblivion without resolution. I'm glad to see it resurrected here, in hopefully a very rational fashion. Being new here, I'm just going to respond randomly with my own thoughts and to various points made by others. If this is verboten and you'd prefer I reply to commenters individually, let me know and I'll do so by deleting and segmenting this post.
|
|
As promised, here are my thoughts. For context: I'm mainly active on the technical/engine side of things. I have no experience in age creation. I've only contributed small content fixes and helped with testing on Minkata, but not as much recently, so I'm probably missing some context/subtext about Current Events™. The way I read it, the overall message of these guidelines is:
Is that correct? I agree with what @patmauro said and I think the new wording "Revert" makes more sense. It could also be helpful (especially for future submissions) to differentiate between rejections because of minor/fixable issues vs. major/fundamental incompatibility with the guidelines. In pull request terms: if a submitted age e. g. has bad lighting, it would get a "Changes requested" review, but if e. g. its premise goes against established lore, the PR would be closed completely. Beyond that, I'm confused by the first paragraph about subjective submissions. It seems contradictory at first: submissions must have gone through a review process by certain people, but the process is explicitly undefined and it's not explained who the people are, but you can ask H'uru maintainers if you want to know about the process or the people..? I'm guessing the intent is to say "before submitting content to this repo, someone other than the creator/submitter must earnestly look at the content and consider it good" without formalizing the process too much or restricting it to a closed circle of reviewers. If so, I think that should be worded more clearly. The project goals seem fine overall. I think the part about "integrating new content/Ages that serve a clear purpose in enhancing Myst Online: Uru Live as a video game" will be tricky to handle in a consistent and fair way, because different people have different opinions on what content "enhances" the game. Specifically: what happens if the H-uru/moul-assets reviewers consider a submission a clear enhancement, but other community members disagree? It would be nice if that could be defined more clearly, but that's probably difficult without making it much more conservative (e. g. "no original fan content, only enhancements to Cyan content"). The non-goal "accepting fan content geared toward role-playing done on any particular shard" is especially tricky IMO, and I don't see how this follows from the other goals. Not to rehash the whole RP/storytelling discussion, but Cyan has integrated "role-playing" with Uru game content on multiple occasions. If this non-goal was followed consistently, you would have to remove e. g. parts of Douglas Sharper's journal, the dead Bahro in the Watcher's Pub, and possibly Phil's Relto. This goal would also be less tricky to enforce if it clearly said "no fan content geared toward fan role-playing", but even that leaves some things unclear, e. g. the Heritage Documents books in Chiso Preniv. The other requirements for subjective changes, as well as the rest of the guidelines, look reasonable and good to me - I have no major thoughts on those. |
I've been meaning to try something like this, at least for the content side, as I've hinted at a few times in the OpenUru Discord. Can't promise when I'll actually do it though, so if anybody else is motivated to set this up, go ahead. My plan would be to fork H-uru/moul-assets at the first commit of compiled game content (fe10174), which corresponds almost exactly to Build 918.OpenUru=138, and then apply the incremental delivery bundles from the OpenUru Foundry-MOULa-Delivery repo. The resulting commit history should precisely match the history of builds released by Cyan, because these delivery bundles are what gets sent to Chogon to be put on Cyan's file server. This approach would rely on the GoW Gitea for LFS storage space. I expect that this project won't require much additional space at the moment, because all (or almost all?) the content published on Cyan's MOULa server has been merged into or at least submitted to H-uru/moul-assets, so the data files already exist in the LFS storage and will be shared without consuming additional space. That would change in the future though if H-uru/moul-assets becomes more conservative about what submissions it accepts. It would also become tricky if Cyan decides to publish content with unclear licensing (e. g. Direbo) that the GoW may not be comfortable with hosting. If the GoW doesn't want to host this "Cyan-identical" repo for the reasons above, I would probably attempt the same approach as a fork of OpenUru's MOULa-current-content repo. This would allow reusing the LFS storage space even more efficiently, because all content submitted to Cyan will have gone through that repo at some point. |
Hoikas
added
documentation
|
I wanted to chime in on this again, as it was recently brought up here by @Hoikas : #261 (comment)
So I'm just a contributor to this repo - a "guest" in your home, so to speak - so I certainly don't want to overstep / be presumptuous here. :) That said, I'd like to offer my 2 cents on this based on everything I've seen: I'm actually in complete agreement that simply backing out all fan Ages (with some exceptions) is probably the way to go for you guys - not only will this give this Repo a better defined "mission statement" as it were (being the best possible starting point upon which a shard can be built), but quite simply it will make managing your assets repo far easier going forward once these expectations are codified. That said - for reasons that have previously been mentioned, I would keep the trifecta of Chiso, Veelay & GoMePub, as these sort of form the "bedrock" upon which fan content can be built, and for various reasons it does make sense to keep them as part of this set. The challenge will be making sure these are modular enough that they can accept additional updates when they happen without including any of the RP and/or fan age content in those updates - Chiso, for example, is updated frequently, and while most of these updates are to accommodate new fan content, a lot of the changes are not related to fan content and are simply improvements to the baseline Chiso Age - we'd need a way to keep updates like this while still filtering out anything that falls under the umbrella of "RP" or "fan age content." This probably comes down to how the PRPs are handled and just making sure content is packaged in the PRPs in a modular way. Otherwise - as long as the PR in question does not cover a new "fan age" and is simply an optimization or improvement to existing content, I do think you should consider keeping these. This is generally the way you have been doing things, and I think it makes sense to codify that officially. By setting the criteria this way, which is very clear and realistically sets expectations, I think you can probably do away with the "endorsement" concept as it's been used so far - While I do think, perhaps, this could be useful when defining the circumstances under which an exception would be made to the "no additional fan ages" rule, I don't think "endorsements" are useful criteria when the PR in question covers an improvement to base/existing content (lake lighting, blue flowers, etc), and it hasn't been something we've really been adhering to when evaluating other similar submissions. That said, you still have a robust vetting process and I think it's reasonable to say that you reserve the right to reject a submission if you feel it is inappropriate. So - keeping this criteria in mind, let's go through the list...
All other Fan Ages would be retroactively removed if already accepted, and rejected if the PRs are outstanding:
But going off of this criteria, I'd see no issue with accepting/keeping anything that simply tinkers with & improves existing content (especially if those improvements were merged over in OU, to prevent PRPs from diverging too much). Such as:
To get into a hypothetical, were Tweek's Gateway Nexus to be submitted, I think this would also be something we would keep, as rather than being "Fan Age Content" this is designed to supplement Chiso and provide a convenient way of navigating the additional content, which makes this a valuable asset for any shard. So what do we think? I think if you just make this a clear-cut "This Repo does not accept any fan age content (aside from Chiso, Veelay and GoMePubNew), but does accept updates/improvements to existing content as long as it does not otherwise violate any of our stated rules." this will not only set realistic expectations, but provide a path for how this repo can be managed going forward. You could even clarify this with something to the extent of "submissions will be vetted by our team and we reserve the right to reject any submissions if we feel they are not warranted or will cause issues," etc. |
|
You beat me to the punch, and much more comprehensively. I still need to go through all the PRs and make my own determination, and hopefully cajole some other maintainers into looking at things as well. I do find myself a little on the fence about the trifecta you mention, especially Chiso. My primary concern with it is that it has begun to accumulate quite a bit of storyline specific stuff, and it's not particularly modular in that currently it requires a re-export to add/remove/modify linking books. My secondary concern is that it's harder to codify the "rules" in the contributor's guide if we do have some fan Ages that we've accepted. Perhaps if the rules were worded to indicate only new Ages that serve a unique goal/niche will be considered? And, of course, it should be said.... Backing out any Ages isn't a comment on their quality or the work put in by the author - it's just a change in our direction. |
|
I've adjusted the contributing document to state that we're not interested in the submission of unsolicited Ages. That basically means (for new Ages).... don't call us, we'll call you 🤣. |
There was a problem hiding this comment.
Just noticed that I had a few old review comments pending... Only small wording changes though, nothing significant.
@Hoikas Also, you might want to re-check the previously resolved review comments left by others. I think some of the suggested changes were accidentally undone in your last force push.
Co-authored-by: Joseph Davies <[email protected]>
Co-authored-by: dgelessus <[email protected]>
|
It looks like it's time for both this document and the "don't call us, we'll call you" policy to land. |
This repository exists in an odd state where it kinda matches MOULa but not really. So, I've written up a draft contributor guide that lays out where I think this repo should fall in the ecosystem. Specifically, we are not trying to be the MOULa repository - that's not been our goal, ever really. Our goal, generally speaking, has been to provide a high quality baseline for any shard to operate off of.
One of our main sources of difficulty is that a lot of things that have been tested on Minkata and deployed to MOULa. Unfortunately, Minkata is a testing environment, not a review environment. This has led to content going to Cyan's shard that, even in cases going back almost a decade, isn't particularly up to snuff with the rest of the game. This has been accelerating over the last couple of years and has been putting us in an awkward position where we have a lot of open pull requests whose purpose is basically to match what's on MOULa but not to actually receive feedback.
So, I've codified that we aren't trying to match MOULa exactly (but we also don't want to break it), and we also don't want to be the initial submission point for new Ages. There still isn't an official process, but this at least draws the line in the sand, so to speak, that we expect for content to go through some kind of review process. Ideally, this will be with community members that we know have a keen eye for details both in regard to canon and art. I'm not sure we should explicitly list those people out, so I labelled them as "discerning members" in the document.
With this guide in place, we will need to re-evaluate all fan content that we've accepted and determine whether or not it falls in line with the new guidelines. My initial observations are:
Note that rejection does not necessarily mean that the Age or content is not good, rather, it doesn't comply with the procedure set forth for inclusion. I want to avoid personally endorsing anything new for the purpose of this PR, but there are some things that I endorsed back in the Gehn era.
When applying these rules to the open PRs, we need to close (with the potential for re-opening on endorsement):
Finally, we'll probably want to seriously consider having another repository (or org) that tracks what's actually on MOULa. The goal of this repo/org won't be to act on pull requests. Rather, it should be a fork of both Plasma and moul-assets containing the code and assets required to play specifically MOULa using the superior client. Ideally, this would be unnecessary; however, OU continues to a roadblock in terms of actually progressing the ecosystem as a whole. It would be nice if we could farm the maintenance of that out to someone else (who isn't me)