Principles and Vision

Anything related to PR, release planning and any other non-technical idea how to move the project forward should be discussed here.
User avatar
Zini
Posts: 5120
Joined: 06 Aug 2011, 15:16

Re: Principles and Vision

Post by Zini » 14 Sep 2017, 15:08

With the project set up as it is losing main developers wouldn't kill it and we are also reasonably well equipped to deal with an larger influx of new developers.

However I am not opposed to the idea of letting community members help with curating the list of ideas from the feature request forum in one way or another. There is a really large number of threads in there and having non-developer community members helping with filtering out that list would save the devs a lot of time. But that is still quite a while in the future and we should revisit the issue once we are at or around 1.0.

User avatar
scrawl
Posts: 2050
Joined: 18 Feb 2012, 11:51
Contact:

Re: Principles and Vision

Post by scrawl » 14 Sep 2017, 22:29

It sure would be nice to bring some order into the chaos of feature requests. Seems to me we get too many requests, too little discussion and too little collaboration between requesters.

Currently, we have:
* Wishlist on wiki (some requests are OK, some are strange and/or already implemented features)
* Feature requests forum category (not sure, I don't look at it much)
* Feature requests on bugtracker (weird place: some are technical requests created by developers, others are very vague, non-systemic requests)

For starters, could we enact a policy that the bugtracker should only be used for fully specified and reasonable feature requests on a technical level? This way, we avoid wasting developer time with categorizing things like 'I want flying horses', and by having different outlets for different audiences we will hopefully make it easier for the community to discuss and collaborate more. We can add this as a footnote of 'Bug reporting guidelines', saying that we welcome feature requests but we suggest for non-technical users to discuss their ideas on the forum first, especially if they are post-1.0 features. After that, we can reject all the feature requests on the bugtracker that are too vague and request them to be brought to the forums instead.

User avatar
raevol
Posts: 2400
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: Principles and Vision

Post by raevol » 15 Sep 2017, 01:47

scrawl wrote:
14 Sep 2017, 22:29
enact a policy that the bugtracker should only be used for fully specified and reasonable feature requests on a technical level
This is not really my domain, but I 100% support this. "Fully Specified and reasonably feature requests that have been approved by the team" or similar might be a good thing to add.

User avatar
DecumusScotti
Posts: 26
Joined: 08 Jul 2016, 17:26

Re: Principles and Vision

Post by DecumusScotti » 15 Sep 2017, 03:21

Yeah, feature requests that are not suggestions as to how to solve a bug don't belong in the big reports section. I totally agree.

Okay, thanks for the feedback. If you think such a list may actually be of use to the devs, then I'll stick a pin in it and come back to compiling it once it makes sense and once I have the time (the latter probably around December).
Zini wrote:With the project set up as it is losing main developers wouldn't kill it and we are also reasonably well equipped to deal with an larger influx of new developers.
Then even better. As I said, I don't know too much about the inner workings of the openMW development process. Knowledge management was always a problem in those groups I've been in that relied on unsalaried work, but I'm glad to hear that I needn't worry about that here :)

User avatar
Thunderforge
Posts: 154
Joined: 06 Jun 2017, 05:57
Github profile: https://github.com/Thunderforge

Re: Principles and Vision

Post by Thunderforge » 15 Sep 2017, 04:26

Generally speaking, I'm in favor of Feature Requests requiring discussion on the forums first. In fact, several of the feature requests I've created only happened after posting on the forums.

I'm concerned that adding a footnote to the Wiki won't be enough and may wind up biting new people. If their first thing is a feature request for X, and we immediately reject it, then it's a pretty poor first experience.

Perhaps it would be better to let anybody with an account create bug reports, but only developers could create feature requests. Hopefully those with that power would be responsible enough to only create them if there is enough consensus on the forums.

Of course, that brings us back to the perennial issue of there not being a clear way to get developer access. Maybe we should formalize that too (maybe have a separate topic about it).

User avatar
Zini
Posts: 5120
Joined: 06 Aug 2011, 15:16

Re: Principles and Vision

Post by Zini » 15 Sep 2017, 15:13

I would prefer to gather all feature requests into one place (the forum). As scrawl said having fully specified technical requests on the tracker is tolerable, but other feature requests don't really belong there.

I consider the requests section on the wiki to be irrelevant. Too outdated and mostly redundant.

As for not having enough discussion about features, that is probably a 1.0 issue. There really isn't a whole lot to discuss since we have relative precise specs (in the form of the vanilla engine). And we don't discuss post 1.0 features much. It is just too early for that.
Perhaps it would be better to let anybody with an account create bug reports, but only developers could create feature requests.
IMO that is not a bad idea. @scrawl?
Of course, that brings us back to the perennial issue of there not being a clear way to get developer access.
You get developer access by being a developer, i.e. by contributing code. In earlier times I manually added access whenever I added a new developer to the CREDITS file. I have mostly given up on that because:

a) scrawl does a lot of adding new devs now
b) people often don't have tracker accounts when they send a PR or their accounts have different names (and frankly I can't be bothered to hunt after the correct names anymore).

Right now the only way to get developer access is to PM me on the forum, to which I should react within 23-36 hours (depending on how busy I am). I don't think there is a way to automate that (though I would be very happy if there was).

User avatar
AnyOldName3
Posts: 458
Joined: 26 Nov 2015, 03:25

Re: Principles and Vision

Post by AnyOldName3 » 15 Sep 2017, 18:01

How do I check if I've already done that?

User avatar
Ravenwing
Posts: 127
Joined: 02 Jan 2016, 02:51

Re: Principles and Vision

Post by Ravenwing » 15 Sep 2017, 21:23

I think limiting the bug tracker permissions to the essentials will help increase the signal to noise ratio for developers and decrease confusion among users, so a win win. This applies to feature requests and to setting version numbers, as discussed in that thread.
Zini wrote:
15 Sep 2017, 15:13
I would prefer to gather all feature requests into one place (the forum). As scrawl said having fully specified technical requests on the tracker is tolerable, but other feature requests don't really belong there.

I consider the requests section on the wiki to be irrelevant. Too outdated and mostly redundant.
I completely agree. As a user, it's hard to keep track of where I should be looking to see if we're planning things or not. It also is much harder to maintain multiple sets of information, as evidenced by the wiki being outdated. This was part of the reason we decided to move documentation entirely to ReadTheDocs (WIP). Nobody has time to update that kind of thing because it's hard enough to keep track of anyway, and if they did, there are far more productive things they could be working on. This is not to say we shouldn't have a page describing what our general goals are and the big deal features are, because I think that's necessary for people just introducing themselves to the project. This is probably what the OP was getting at. Wiki is appropriate for general vision, bug tracker for more technical stuff, and the forums for public requests and discussion.

The only problem I see with limiting access to adding feature requests is that users will feel like they don't get input. This is easily rectified by simply linking to the appropriate forum thread(s). This allows for distinction and separation between technical and content focus discussions, at least as long as each feature always links to at least one forum thread. I think searching for specific things in the bug reporting section is easier than in the forum, so it would hopefully help prevent duplicate feature discussions (realistically not, but one can hope).
Zini wrote:
15 Sep 2017, 15:13
As for not having enough discussion about features, that is probably a 1.0 issue. There really isn't a whole lot to discuss since we have relative precise specs (in the form of the vanilla engine). And we don't discuss post 1.0 features much. It is just too early for that.
I don't necessarily agree. It's early to discuss, but not outrageously early. As you say, we don't have many feature requests because everyone's waiting for 1.0. A lot of threads in this subforum get killed pretty quickly because we simply tell people that their feature request won't even be considered until after 1.0 (maybe not in so many words, but in effect that's our main response). Once we hit 1.0, we no longer have that goal to shield us from the inevitable onslaught of everyone's pet features. I think it would be prudent, maybe not immediately, but soon, for the devs to discuss, hopefully with the community, what your immediate set of goals are for post-1.0. I think many of those goals are already pretty solidified, but to effectively stave off the influx of requests from new users, they should be clearly and publicly stated by release, not hidden within forum discussions. We're going to get a lot (relatively) of press with 1.0, and it will look a lot better if we aren't all arguing about our next steps when we get that increased traffic.

User avatar
scrawl
Posts: 2050
Joined: 18 Feb 2012, 11:51
Contact:

Re: Principles and Vision

Post by scrawl » 15 Sep 2017, 23:38

Developer access on the tracker isn't needed for most things. As a 'developer' you additionally get to: 1) assign yourself to issues, 2) change milestone. (There's probably a few more priviledges, but they would fall under triaging/management not development, so a developer isn't necessarily good at them).

1) isn't really an issue if someone else can do it for them. And so is 2), with the additional aspect that we might not want to give roadmap planning priviledges to every developer, just because they fixed a one line typo here or there. We can give this to developers once they have contributed a lot. You could say that having to ask for access is a feature.
Perhaps it would be better to let anybody with an account create bug reports, but only developers could create feature requests.
Not sure about that. My main gripe is with the post-1.0 requests that tend to just sit on the tracker forever with no discussion at all, clog up lists (unless I filter for them) and search results. Requests that can actually be done now (e.g. quality-of-life related) and are technical are definitely appreciated and these can (and have been) submitted by regular users.

Let's just continue as we have, with the premise we reject anything that's too broad / too far in the future / not fleshed out, document this somewhere and see if everyone gets the memo. I suspect that newbie users (the kind who wouldn't notice said rule) are too lazy to submit feature requests anyway (they just complain about broken stuff).

User avatar
Zini
Posts: 5120
Joined: 06 Aug 2011, 15:16

Re: Principles and Vision

Post by Zini » 16 Sep 2017, 13:00

AnyOldName3 wrote:
15 Sep 2017, 18:01
How do I check if I've already done that?
No idea. There doesn't seem to be any indication on the tracker itself. I guess you should have gotten an email when your account was set for developer status. You could try to check that if you still have old emails.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest