WIP: 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? |
Co-authored-by: Joseph Davies <deledrius@gmail.com>
|
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
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)