Issue: Assets that need someone to work on are getting lost in the asset browser. New people come in and can't make heads or tails of the current hodge-podge, so they give up and go away before they find something they can contribute to.
Your task is to take a look at the asset browser and make suggestions on how better to organize it, with an eye towards making priority assets (aka roadblocks to development, assets tied to specific claims, etc) clearly visible to all.
Post your ideas below. Screenshots are awesome to get across your concept!
Link to Asset Browser: http://tamriel-rebuilt.org/asset
2017-08-07 22:53
7 years 3 months ago
My suggestion would be to revamp status options. Everything should start off as something like "new" or "unsorted" to make it easy for leads/moderators to quickly find new entries that haven't been sorted yet so they can review them and update to an appropriate status. The main ones to sort the new ones into could be along the lines of "rejected", "needed" and "wishlist".
"Rejected" doesn't have to be final, but if something about the proposal currently doesn't fit with TR it can be set to rejected and a reason can be given in the comments, if the creator then makes the necessary changes it can be bumped to one of the other status options. "Needed" is fairly self explanitory, if a lead feels the proposal is a good fit for an area under development they can set it to this. "Wishlist" on the other hand would be something that isn't necessary, but fits well with TR and would be a nice addition. If someone really connected with that idea and wanted to scratch an itch by developing it then they are welcome to it, but it would remain a low priority on the whole,
Once work has been done on fulfilling a proposal the status can be changed to "needs review", "finished" or "in-game." Perhaps "needs review" or something equivalent can be one status that a contributer can directly make use of when they feel their work is done, if this can't be done perhaps some sort of flagging button labelled "needs review" can fill a similar role without letting non-leads change status directly. Once a lead signs off on it, it can be updated to "finished" status then perhaps from there finished assets can then become available as claims to be integrated with the TR game files and upon completion the asset can then be changed to "in-game" or similar.
Those status suggestions of course can be changed as needed to something more clear if so desired. In addition to this proposed change it would be good to consider having an automated entry to the comment section any time status has been changed to have a bit of a history to follow, where the entries would include the name of who made the change and what it was changed from and to. So as an example it might look something like: "Kevaar has changed the status from New to Needed." With an appropriate time stamp, just like any other comment would have. There could also be an option for including a reason to be given that would get added to that comment to help streamline things a bit. So if the reason box had anything typed into it that generated comment would add a second line to the comment with something like: "Reason given: blah blah blah."
I also like Gnomey's suggestion of adding a 1-10 priority pull down to the proposal pages that defaults to 1 and can only be changed by leads. Basically in that situation only stuff that has/had the "needed" status should really have that value changed to something higher. Then on the browser page a new column can be added to list the priority values to give another option to sort by.
2016-01-19 19:35
1 month 3 weeks ago
Thanks, Uradamus! The labels you mention like need review or in-game we already have in some form, but the timestamps and reasons could be very useful if it's do-able. Priority drop-down might also be useful, but I'm worried that that will be overlooked as yet another field people don't know what it's for, or abused by people trying to push their particular assets through once they've been rejected or pushed back into editing. Food for thought, not sure that has to make them a no-go.
As for my proposal: fairly simple. Put a row of buttons that filter down the assets, in a similar position and look as the claims browser:
http://tamriel-rebuilt.org/claims
But instead of filtering it by "type" like claims (which can only be claimed by the right "type" of dev), filter the assets by what kind of attention they need. Such as: "Help Wanted", "Needs Reviews", and "Ready for Merging" at least. Maybe a filter for things attached to specific claims (linking assets to claims as parent/children would be great if do-able!), and of course a catch-all like "In Development" for everything else.
I always wondered why intuitive UI's were such a hot topic when I was going through college programming courses...now I know. :P
2017-08-07 22:53
7 years 3 months ago
Having not used the claim system at all and barely touching the current filtering system, I can't really give much input on your suggestions about the filtering. Reference links on asset and claims pages pointing at their related counterparts would make a lot of sense though. As to UI design, I don't envy anyone who takes on such tasks, I'm just glad it doesn't fall to me, heh.
I'm not entirely sure how things work now, being a newcomer who hasn't had a reason to create or edit any proposals myself, so please excuse me if I bring up things that are already implemented. Considering how similar the asset browser is to a traditional issue tracker, it would make a lot of sense to learn from those and incorporate some of their best practices, This point of view is where most of my suggestions stem from, having used several of them over the past decade or so.
For one, privilage based access to management is rather important. There should be a clear line drawn between what can be done by anyone and what can be done only by lead devs. Anyone should be able to add new proposals, comments and contribute new material but only leads should have access to changing status, priority, assignments and other similar things. To me the whole point of having lead developers on a project like this is to primarily steer development and as such they are really the only ones who should be changing status and priority. Which should mitigate most of the issues you pointed out.
Most trackers have a way for users to add themselves to a project. We sort of have that now, but only by way of a notifier via that watch feature as best as I can tell, but I don't get to see who else is watching a proposal. Github in particular adds a small version of your user icon (that links back to your profile) to a box on the side bar filled with the followers when you follow an issue and you automatically receive updates when anything changes or new comments are added. I think we could probably replace the basic notify feature with something more robust that serves a similar purpose, but with the added visibility of who is actively interested in a given proposal.
Another nice feature of a lot of trackers is the use of history entries, which I mentioned briefly in my last comment. Basically any time something changes with an issue - such as title, status, priority, files attached, cross issue references added, etc - an automated entry is made to the discussion/comment section. This builds in accountability since they always include who made the changes and when and allows someone new to review the history at a glance and get a good feel for what's been going on and what stance the involved lead devs have in regards to the proposal. Also as mentioned before, the nicer ones will give you an optional text box to give a reason for your edits, though this is purely for convenience to avoid having to manually add a separate new comment after the change is made when one would be appropriate.
Revisting the priority idea, the 1-10 is a bit vague and we probably don't really need such a granular level of discernment. Most other trackers I've just been looking at just now as a point of reference tend to use a low, normal, high and critical priority setup which is simpler and more straight forward regarding intent.
2015-09-28 20:13
2 years 7 months ago
There is no real reason to use this kind of tracking. We currently do not need it and a previous iteration had it, but it went unused because it was more cumbersome than helpful.
"New" vs "Proposed" make it more clear that it's not yet worked on. However, that doesn't work with the current workflow and access rights system. Might need more consideration. Leads are currently a big bottleneck on anything, too few people, too little time, so I'm not sure "leads will sort it out" is a solution.
All in all, it feels good to know that most of your proposal is already implemented in one form or the other otherwise.
I've put up a rudimentary version with tabs on the Dev Site .- putting the respective filter block up for each page and changing the table fields is more effort so I didn't do it yet; also, in one last attempt to keep the Dashboard relevant, I kept "Ready for Merging" out of it.
Is that, however, the general idea?
2016-01-19 19:35
1 month 3 weeks ago
Not so much an asset browser request as a claims browser request: can child quest claims of questline claims get a separate category or progress state for filtering purposes? Right now I put them into DESIGN rather than UNCLAIMED so that they don't clog up the claims browser when people are searching for unclaimed quests (as preferrably people claim an entire questline rather than piecemeal), but that method is a bit nonintuitive.
Another possibility is not to make the individual quests into child claims, but come up with a method to make them more easily organizeable in the parent quest claim page. Liberal use of spoilers?
Example: http://tamriel-rebuilt.org/claims/foul-murder-questline
With one of its child quest claims in Design: http://tamriel-rebuilt.org/claims/outcasts-ringlet
2015-09-28 20:13
2 years 7 months ago
I don't know - Design sounds like it's working as intended. I could make another progress stage for it, but it would functionally be identical to In Design.
I guess what would be useful here is some sort of automatical batch switching claims "on" when the previous claim in a chain has been finished.
2015-08-10 20:50
3 weeks 1 day ago
Ok, finally getting around to replying here. As I said in the last meeting, I think the status of assets should be tracked by three values: the file progress, set by asset developers; the priority of the asset, set by senior and lead developers; and the stage of the asset on the implementation pipeline, which can be set by different people depending on the stage.
The values can be set to the following:
File progress ranges from 0 to 100. 0 means that the asset does not yet exist. (Strictly speaking that it has not been posted on the site in any form). 100 means the asset is ready for review.
Asset priority can be set from the default 'unsorted' to 'low', 'medium', 'high' and 'bottleneck'. If an asset is unsorted, it's the responsibility of leads to sort or reject (close) it. This effectively replaces (and expands) on the function of the 'requested' stage, and renders it obsolete.
As far as implementation stages are concerned, I'm not completely sure on what the first ones should be called, but for now I'll go with 'proposed', 'requires work', 'pending review', 'in review', 'ready for merging', 'merged' and 'closed'.
I think how the implementation stages currently work is fine, we just need to be more organized and consistent in using them:
'Proposed' is where assets sit until they are sorted by seniors/leads, so hopefully it will in future be kept fairly clean. The only reason, aside from seniors/leads being too slow, why an asset might sit around in 'proposed' is if seniors/leads decide the proposal needs more work before it is accepted. Basically, if they do not outright reject the asset, but are not wlling to accept it in its current state.
Assets that are accepted, if their progress is not already 100, go to 'requires work'. There are no other considerations; it doesn't matter if no developer is actively developing the asset, if ten are, or if its progress is 0. If it's accepted and not ready to review, this is where it belongs.
Assets that have their progress set to 100 always go to 'pending review', whether they are in 'proposed' or 'requires work'. If an asset in pending review has its priority set to unsorted, that means that while the asset itself is ready for review, it has not yet been accepted by seniors/leads. Reviewers should generally only review assets with a priority set, unless they have nothing better to do with their time.
Pending review, in review, ready for merging and merged work the same as with claims, and I assume I don't need to explain those. 'Closed' is for assets that are rejected, and maybe some other fringe cases, but whatever goes there will probably quickly be forgotten, so beware.
In general, I'd say priority is the single most important value; seniors/leads should be keeping their eye out for assets with no set priority to sort them, and everyone else should be looking at the priority of an asset to figure out how worthwhile it is to work on, if at all. (Of course, nobody is going to stop anyone from working on a low priority or unsorted asset if that's what they want to do).
File progress is only really relevant by itself to asset developers, to get an idea of how much work is needed on the asset. The most important stage, 100, automatically corresponds to the asset landing in 'Pending Review'.
As a last point, while I generally think it's more convenient if terms are shared between claims and assets, I think that specifically for 'design' and 'proposed' and 'in development' and 'requiring work', the terms need to be different because their purpose is very different.
Claims are created by seniors/leads, and should only really be created if it has already been decided that they're desired. The purpose of 'design' is to take the accepted idea and narrow it done and clarify it. This as opposed to proposals, which can be created by anyone and only exist as proposals until they are accepted; the start point of the one is the end point of the other.
In development is automatically linked to unclaimed; the whole point of the claim system is that once a developer has grabbed a claim nobody else should work on it until it has been dropped again or is being reviewed. As long as a claim is in development, it's off-limits to everyone else. As soon as it is revoked, it returns to unclaimed. Anyone can come in at any time and develop the asset. Of course, in practice, it might work out better for one person to work on an asset at any given time, but that is something to be decided between developers on a case-by-case basis, not by the system. Assets are specifically not supposed to have that sort of commitment; asset developers should not immediately turn away if they see an asset 'requires work', even if is already being developed by someone, as it's possible their help may still be needed, eg. a modeller wanting someone else to take care of the textures. If a claim 'in development' isn't being worked on, eventually leads need to come along and revoke it. If an asset with an assigned developer isn't being worked on, a new developer can hop in at any time and continue work on it. This is the whole reason the asset browser exists as a separate entity to the claims browser, and needs to be made clear to everyone if we want the asset browser to function correctly.
Edit: oh right, goodness knows I made this post long enough, but just to be clear, I think the requirement for an asset to be accepted or rejected should be for at least two leads (probably not including the one who proposed the asset, if it was proposed by a lead) to agree on what to do with it. It would be expedient if the second lead to agree were to edit the asset right away (either moving it to closed or giving it the agreed-upon priority and moving it to 'requires work', if it's not already in 'pending review').
2016-01-19 19:35
1 month 3 weeks ago
Gnomey, you just put everything in my head into words way more clearer than I could, so good job! In short, I agree completely with your suggestions and your reasoning.
As far as Quest claims and Design vs. a new category--let's use the Design for Child quest claims for now. Less work for everyone involved, so long as our leads remember to properly organize their quest claims this way. It might be worth it discussing the quest claim pipeline at a meeting just so everyone's on the same page though.
2016-10-09 23:10
21 min 34 sec ago
This all sounds great Gnomey! "Requires Work" is a stroke of genius (or chance) that perfectly fits what it should be.