Proposed new rule for developers

How, what and why to code in BYOND.
User avatar
oranges
Code Maintainer
Joined: Tue Apr 15, 2014 9:16 pm
Byond Username: Optimumtact
Github Username: optimumtact
Location: #CHATSHITGETBANGED

Proposed new rule for developers

Post by oranges » #265321

1 Feature PR open at a time only

Unlimited fix pr's are allowed and I guess we would handle tweaks on a case by case basis dependent on size.


This is to manage the size of the tracker for maintainers (mostly me) as I'm getting overwhelmed by the speed of the tracker.

More importantly it also makes people focus on one pr and get that ready and merged and respond to maintainer feedback straight away.

The atomization rule would still be in place as well.

Yes this slows the rate of change a bit, but I think that it is required.
User avatar
danno
Joined: Wed Apr 16, 2014 5:07 pm
Byond Username: Dannno
Location: e-mail me if you want a pizza roll

Re: Proposed new rule for developers

Post by danno » #265326

Sounds like a good idea honestly
Hornygranny wrote: wtf i like danno now
Image
I don't even play ss13 anymore, pretty much due to dannos stupid bullshit
User avatar
Qbopper
Joined: Fri Jul 10, 2015 6:34 pm
Byond Username: Qbopper
Github Username: Qbopper
Location: Canada

Re: Proposed new rule for developers

Post by Qbopper » #265327

I'm in favour, hopefully would lead to people focusing on polishing and finishing existing PRs they're working on over jumping between them

i dunno if that was ever an issue, but yeah
Limey wrote:its too late.
User avatar
Cyberboss
Code Maintainer
Joined: Mon Sep 26, 2016 7:58 pm
Byond Username: Cyberboss
Github Username: Cyberboss
Location: Ontario, CA
Contact:

Re: Proposed new rule for developers

Post by Cyberboss » #265332

I'm for it
ImageImage
User avatar
iamgoofball
Github User
Joined: Fri Apr 18, 2014 5:50 pm
Byond Username: Iamgoofball
Github Username: Iamgoofball

Re: Proposed new rule for developers

Post by iamgoofball » #265335

This is dumb

But I understand why
Last edited by iamgoofball on Thu Mar 09, 2017 9:56 pm, edited 1 time in total.
User avatar
Jordie0608
Site Admin
Joined: Tue Apr 15, 2014 1:33 pm
Byond Username: Jordie0608
Github Username: Jordie0608
Location: Spiderland, Australia

Re: Proposed new rule for developers

Post by Jordie0608 » #265336

I foresee this calling into debate what exactly is a feature, fix or tweak; mayhaps be good to decide on suitable boundaries for each before this.
Forum Admin
Send me a PM if you have any issues, concerns or praise of fishfood to express about the forums.
User avatar
iamgoofball
Github User
Joined: Fri Apr 18, 2014 5:50 pm
Byond Username: Iamgoofball
Github Username: Iamgoofball

Re: Proposed new rule for developers

Post by iamgoofball » #265337

Jordie0608 wrote:I foresee this calling into debate what exactly is a feature, fix or tweak; mayhaps be good to decide on suitable boundaries for each before this.
This too
Incoming
Github User
Joined: Tue Apr 15, 2014 11:41 pm
Byond Username: Incoming
Github Username: Incoming5643

Re: Proposed new rule for developers

Post by Incoming » #265358

Damn son I guess your limit wasn't much further than mine after all.

100% for this, maybe more. Update 3/10: Mellowed out on this intensely, not sure anymore that it'd [work / be a good thing]

Though it needs an exception for feature pulls that are already feature complete, lest a controversial but finished pull be used as a tool of attrition to punish people by leaving it open forever.
Last edited by Incoming on Fri Mar 10, 2017 6:29 pm, edited 1 time in total.
Developer - Datum Antags: Feburary 2016

Poly the Parrot - All Seeing Bird Transcends Universe, Joins Twitter.

Kofi - Make A Poor Life Choice

Good ideas backed by cruddy code since 2012!
User avatar
PKPenguin321
Site Admin
Joined: Tue Jul 01, 2014 7:02 pm
Byond Username: PKPenguin321
Github Username: PKPenguin321
Location: U S A, U S A, U S A

Re: Proposed new rule for developers

Post by PKPenguin321 » #265400

Why not let on more maintainers instead of handling 99% of the PRs by yourself, oranges?
i play Lauser McMauligan. clown name is Cold-Ass Honkey
i have three other top secret characters as well.
tell the best admin how good he is
Spoiler:
Image
Incoming
Github User
Joined: Tue Apr 15, 2014 11:41 pm
Byond Username: Incoming
Github Username: Incoming5643

Re: Proposed new rule for developers

Post by Incoming » #265402

I maintain that oranges isn't actually that project critical, he's just the least tolerant of open pull requests. If he let more things lay open other maintainers would pick up the slack provided the protracted oranges experience hasn't atrophied their merge button abilities too badly. A feature like this would make something like that more practical.
Developer - Datum Antags: Feburary 2016

Poly the Parrot - All Seeing Bird Transcends Universe, Joins Twitter.

Kofi - Make A Poor Life Choice

Good ideas backed by cruddy code since 2012!
User avatar
420weedscopes
Joined: Fri Jan 02, 2015 6:52 pm
Byond Username: 420weedscopes
Location: Bransford, UK
Contact:

Re: Proposed new rule for developers

Post by 420weedscopes » #265407

wasn't this already the case for several months
have i been hot rused
Check out Phoenix Bucket!
TheWiznard wrote:jmad you read a book out loud to no one for two hours
original fanart by TheWiznard http://i.imgur.com/TTd3AFt.jpg
MORE http://i.imgur.com/335AGAS.jpg
Image
User avatar
MrStonedOne
Host
Joined: Mon Apr 14, 2014 10:56 pm
Byond Username: MrStonedOne
Github Username: MrStonedOne

Re: Proposed new rule for developers

Post by MrStonedOne » #265443

There has to be protections in place against intentionally delaying shit. not just by maintainers but by people purposely arguing about shit on a pr to keep it open so the submitter just closes it out of frustration so they can move on.

I forsee this being abused by trolls to keep prs they don't like from ever getting in.

I suggest we make it so it is 1 pr, + another pr for each 3 valid fix prs merged since that 1 pr was opened.
Forum/Wiki Administrator, Server host, Database King, Master Coder
MrStonedOne on digg(banned), Steam, IRC, Skype Discord. (!vAKvpFcksg)
Image
User avatar
oranges
Code Maintainer
Joined: Tue Apr 15, 2014 9:16 pm
Byond Username: Optimumtact
Github Username: optimumtact
Location: #CHATSHITGETBANGED

Re: Proposed new rule for developers

Post by oranges » #265446

That adds a lot of bookkeeping overhead MrStonedOne

Besides the only people who can really delay a PR are maintainers
Incoming
Github User
Joined: Tue Apr 15, 2014 11:41 pm
Byond Username: Incoming
Github Username: Incoming5643

Re: Proposed new rule for developers

Post by Incoming » #265494

Actually wait a minute none of this is enforceable at all.
Developer - Datum Antags: Feburary 2016

Poly the Parrot - All Seeing Bird Transcends Universe, Joins Twitter.

Kofi - Make A Poor Life Choice

Good ideas backed by cruddy code since 2012!
User avatar
iamgoofball
Github User
Joined: Fri Apr 18, 2014 5:50 pm
Byond Username: Iamgoofball
Github Username: Iamgoofball

Re: Proposed new rule for developers

Post by iamgoofball » #265503

oranges wrote:That adds a lot of bookkeeping overhead MrStonedOne

Besides the only people who can really delay a PR are maintainers
yes but maintainers don't want to take the fall for a PR that seems unpopular because 3 people spammed 200 comments
User avatar
iamgoofball
Github User
Joined: Fri Apr 18, 2014 5:50 pm
Byond Username: Iamgoofball
Github Username: Iamgoofball

Re: Proposed new rule for developers

Post by iamgoofball » #265504

Incoming wrote:I maintain that oranges isn't actually that project critical, he's just the least tolerant of open pull requests. If he let more things lay open other maintainers would pick up the slack provided the protracted oranges experience hasn't atrophied their merge button abilities too badly. A feature like this would make something like that more practical.
Nope, most maintainers don't touch big feature PRs because of my above post
User avatar
MisterPerson
Board Moderator
Joined: Tue Apr 15, 2014 4:26 pm
Byond Username: MisterPerson

Re: Proposed new rule for developers

Post by MisterPerson » #265506

A fairly high upkeep solution would be no new features while one of your existing features has an outstanding issue. This would require an extreme amount of tagging and usage of projects on every issue, plus a lot of memorization and shit. Probably not feasible, but maybe good to keep in mind in an informal sense.
I code for the code project and moderate the code sections of the forums.

Feedback is dumb and it doesn't matter
User avatar
oranges
Code Maintainer
Joined: Tue Apr 15, 2014 9:16 pm
Byond Username: Optimumtact
Github Username: optimumtact
Location: #CHATSHITGETBANGED

Re: Proposed new rule for developers

Post by oranges » #265519

it would also disqualify 99% of our developersform making any more changes
User avatar
XDTM
Github User
Joined: Fri Mar 04, 2016 8:38 pm
Byond Username: XDTM
Github Username: XDTM
Location: XDTM

Re: Proposed new rule for developers

Post by XDTM » #265540

As long as my feature PRs don't sit unreviewed for a week i'm on board with this
a.k.a. Duke Hayka

Coder of golems, virology, hallucinations, traumas, nanites, and a bunch of miscellaneous stuff.
Gun Hog
Joined: Sat Apr 19, 2014 5:19 am
Byond Username: Gun Hog

Re: Proposed new rule for developers

Post by Gun Hog » #265585

No support.

If the reason for this rule is because the maintainers cannot keep up with the issue tracker, then they should hire additional high-activity, objective maintainers (Cheri, Kor, and RR are excellent models for what a maintainer should be! MSO as well, even though he is not a maintainer). If a coder wishes to make several loosely related changes to the same thing, but the changes are sufficiently different to require atomization, it means that he has to split up his PRs and wait for the first PR to be reviewed before he can open the second.

This especially may hurt coders who work on large projects which require several days or more for development. If such a coder wants to make a non-bug related change to another feature of the game, he is constrained for a rather long time. This might not even be his fault, because maintainers are not always timely in their reviews - especially for larger PRs.

I feel that this would hurt development more than it would improve it. The soft-freeze rule of "One feature One Fix" would be better suited to forcing coders to focus on fixes without locking them down in some cases.

TL;DR: Do not slow down the coders. Add more maintainers to handle them.
User avatar
NikNakFlak
In-Game Admin
Joined: Thu Apr 17, 2014 5:08 pm
Byond Username: NikNakflak

Re: Proposed new rule for developers

Post by NikNakFlak » #265630

Gun Hog wrote: If the reason for this rule is because the maintainers cannot keep up with the issue tracker, then they should hire additional high-activity, objective maintainers (Cheri, Kor, and RR are excellent models for what a maintainer should be! MSO as well, even though he is not a maintainer). If a coder wishes to make several loosely related changes to the same thing, but the changes are sufficiently different to require atomization, it means that he has to split up his PRs and wait for the first PR to be reviewed before he can open the second.
Better than having like 5 controversial PRs open at once and have them pushing the shit PRs towards merging at all costs
This especially may hurt coders who work on large projects which require several days or more for development. If such a coder wants to make a non-bug related change to another feature of the game, he is constrained for a rather long time. This might not even be his fault, because maintainers are not always timely in their reviews - especially for larger PRs.
Don't open your PR or open and close it? It's really not that hard to manage open PRs and Closed PRs and still manage your code workflow.
I feel that this would hurt development more than it would improve it. The soft-freeze rule of "One feature One Fix" would be better suited to forcing coders to focus on fixes without locking them down in some cases.
Didn't really work out super well the last time, why would it be better any other time around? Really was just "meh" status.
Incoming
Github User
Joined: Tue Apr 15, 2014 11:41 pm
Byond Username: Incoming
Github Username: Incoming5643

Re: Proposed new rule for developers

Post by Incoming » #265633

My new opinion is that this is a good thing that coders should strive to maintain personally, but trying to implement it as policy seems really hard and/or just doomed to piss people off for very little gain.

More maintainers might help, but that' should be tied to maintainers splitting Pull Requests more evenly between them casually.
I'd probably take up a maintainer position these days if asked. Probably wouldn't be very aggressive in the merge game though.
Developer - Datum Antags: Feburary 2016

Poly the Parrot - All Seeing Bird Transcends Universe, Joins Twitter.

Kofi - Make A Poor Life Choice

Good ideas backed by cruddy code since 2012!
User avatar
oranges
Code Maintainer
Joined: Tue Apr 15, 2014 9:16 pm
Byond Username: Optimumtact
Github Username: optimumtact
Location: #CHATSHITGETBANGED

Re: Proposed new rule for developers

Post by oranges » #265652

Gun Hog wrote:If the reason for this rule is because the maintainers cannot keep up with the issue tracker, then they should hire additional high-activity, objective maintainers (Cheri, Kor, and RR are excellent models for what a maintainer should be! MSO as well, even though he is not a maintainer)..
None of three people you mentioned are approaching anything like a reasonable merge rate to keep up the with the workload.

Anturk and Razharas are the only ones who are even semi active in merging prs.
bman
Github User
Joined: Fri Oct 14, 2016 4:55 pm
Byond Username: Basilman
Github Username: Militaires

Re: Proposed new rule for developers

Post by bman » #265673

oranges is like the ghost in spelunky

if u dont finish up quick he's gunna git ya
Incoming
Github User
Joined: Tue Apr 15, 2014 11:41 pm
Byond Username: Incoming
Github Username: Incoming5643

Re: Proposed new rule for developers

Post by Incoming » #265674

Well I mean there's more to maintaining something than just merging everything. In some ways more merging promotes more development, people see a short turn around time and lower standards and they get excited. If it's getting too frantic to handle adding more heavy merging people is really just a temporary solution. Maybe the solution is to get more selective so people cool off a bit and put more thought into what they're proposing.
Developer - Datum Antags: Feburary 2016

Poly the Parrot - All Seeing Bird Transcends Universe, Joins Twitter.

Kofi - Make A Poor Life Choice

Good ideas backed by cruddy code since 2012!
User avatar
oranges
Code Maintainer
Joined: Tue Apr 15, 2014 9:16 pm
Byond Username: Optimumtact
Github Username: optimumtact
Location: #CHATSHITGETBANGED

Re: Proposed new rule for developers

Post by oranges » #265691

what do you think this thread is for
User avatar
Remie Richards
Joined: Thu Apr 17, 2014 7:11 pm
Byond Username: CrimsonVision
Location: England, UK, Earth, Sol, Milky Way, Local Group, Virgo Supercluster, Known Universe
Contact:

Re: Proposed new rule for developers

Post by Remie Richards » #265698

oranges wrote:
Gun Hog wrote:If the reason for this rule is because the maintainers cannot keep up with the issue tracker, then they should hire additional high-activity, objective maintainers (Cheri, Kor, and RR are excellent models for what a maintainer should be! MSO as well, even though he is not a maintainer)..
None of three people you mentioned are approaching anything like a reasonable merge rate to keep up the with the workload.

Anturk and Razharas are the only ones who are even semi active in merging prs.
atleast I actually review.
私は完璧
Incoming
Github User
Joined: Tue Apr 15, 2014 11:41 pm
Byond Username: Incoming
Github Username: Incoming5643

Re: Proposed new rule for developers

Post by Incoming » #265703

oranges wrote:what do you think this thread is for
Well yeah that's why I brought it up. I agree with the general sentiment you're feeling here.
Developer - Datum Antags: Feburary 2016

Poly the Parrot - All Seeing Bird Transcends Universe, Joins Twitter.

Kofi - Make A Poor Life Choice

Good ideas backed by cruddy code since 2012!
User avatar
ThanatosRa
Rarely plays
Joined: Fri Apr 18, 2014 4:07 pm
Byond Username: ThanatosRa
Location: Las Vegas, Nevada, USA

Re: Proposed new rule for developers

Post by ThanatosRa » #265726

Even though I'm not really a participant in the development process, I would be concerned as well about this being used to filibuster features.
my forum gimmick is that no one knows who i am

gender is irrelevant NO UR IRRELEVANT
u a bish
y u heff 2 b med
onleavedontatme
Joined: Fri Mar 13, 2015 10:26 pm
Byond Username: KorPhaeron

Re: Proposed new rule for developers

Post by onleavedontatme » #265743

I'm not sure this is the right solution but its honestly pretty exhausting trying to keep up, especially since tons of PRs lead to bitter arguments.

I want to start aggressively closing PRs that dont have any justification for their existence in the OP as well rather than beg people for the reasoning but last time I tried that other maintainers reopened them.
onleavedontatme
Joined: Fri Mar 13, 2015 10:26 pm
Byond Username: KorPhaeron

Re: Proposed new rule for developers

Post by onleavedontatme » #265744

Jordie0608 wrote:I foresee this calling into debate what exactly is a feature, fix or tweak; mayhaps be good to decide on suitable boundaries for each before this.
Same rules as the feature freeze for what counts as a feature should work okay.
User avatar
oranges
Code Maintainer
Joined: Tue Apr 15, 2014 9:16 pm
Byond Username: Optimumtact
Github Username: optimumtact
Location: #CHATSHITGETBANGED

Re: Proposed new rule for developers

Post by oranges » #265784

Remie Richards wrote:
oranges wrote:
Gun Hog wrote:If the reason for this rule is because the maintainers cannot keep up with the issue tracker, then they should hire additional high-activity, objective maintainers (Cheri, Kor, and RR are excellent models for what a maintainer should be! MSO as well, even though he is not a maintainer)..
None of three people you mentioned are approaching anything like a reasonable merge rate to keep up the with the workload.

Anturk and Razharas are the only ones who are even semi active in merging prs.
atleast I actually review.
That's cool too, i just want to see you merge more pr's after you review them
User avatar
Remie Richards
Joined: Thu Apr 17, 2014 7:11 pm
Byond Username: CrimsonVision
Location: England, UK, Earth, Sol, Milky Way, Local Group, Virgo Supercluster, Known Universe
Contact:

Re: Proposed new rule for developers

Post by Remie Richards » #265928

I do, Its just i do most of my review on my lunch break these days, so by the time it's merge time I'm on the bus in the middle of no wifi land.
By then someone's usually snapped it up.

There's other cases too, but it really is mostly just other people doing it before me.
私は完璧
onleavedontatme
Joined: Fri Mar 13, 2015 10:26 pm
Byond Username: KorPhaeron

Re: Proposed new rule for developers

Post by onleavedontatme » #265952

Last night before I went to bed I counted 29 open PRs that showed "a day ago" or more recently on github. I know we speedmerged several yesterday as well.
User avatar
Steelpoint
Github User
Joined: Thu Apr 17, 2014 6:37 pm
Byond Username: Steelpoint
Github Username: Steelpoint
Location: The Armoury

Re: Proposed new rule for developers

Post by Steelpoint » #265953

One feature PR open at a time seems like a good idea.
Image
AnturK
Code Maintainer
Joined: Fri Apr 18, 2014 4:42 pm
Byond Username: Anturke

Re: Proposed new rule for developers

Post by AnturK » #265960

I wouldn't really mind this rule but i think bigger issue is the forever WIP PRs with sap the time of maintainers and creators.
User avatar
kevinz000
Joined: Fri Nov 14, 2014 8:41 am
Byond Username: Kevinz000
Github Username: kevinz000
Location: Dorm Room 3

Re: Proposed new rule for developers

Post by kevinz000 » #266107

personally i'd hate this because i make shitcode and shitfeatures and have like 3 stale memes open
but in the end this would be a good change to make that stuff not happen :^)
User avatar
bandit
Joined: Thu Apr 17, 2014 7:35 pm
Byond Username: Bgobandit

Re: Proposed new rule for developers

Post by bandit » #266413

I wouldn't mind this, but the 1 fix = 1 feature solution would work as well, and give coders more freedom to propose multiple features as long as they are willing to do the effort rto fix shit.
"I don't see any difference between ERP and rape." -- erro

admin feedback pls
User avatar
oranges
Code Maintainer
Joined: Tue Apr 15, 2014 9:16 pm
Byond Username: Optimumtact
Github Username: optimumtact
Location: #CHATSHITGETBANGED

Re: Proposed new rule for developers

Post by oranges » #266523

I think my solution is the easiest to implement

Bandit's is also a good one that we have tried before with varying success, it still leads to too many feature pr's open imo though.

As it is, doing absolutely nothing is unsustainable.
User avatar
iamgoofball
Github User
Joined: Fri Apr 18, 2014 5:50 pm
Byond Username: Iamgoofball
Github Username: Iamgoofball

Re: Proposed new rule for developers

Post by iamgoofball » #266525

what if after a feature gets added, no revert/balance PRs by anyone other than the creator for 1-3 week(s) unless said creator drops off the face of the earth during that time

i feel like that idea will lets content creators actually fine tune their work themselves instead of trying to PR their post-launch balance amid 2 revert PRs and 3 more "totally not a revert but makes it useless" prs fighting them
lzimann
Joined: Sun Oct 26, 2014 5:13 am
Byond Username: Lzimann
Github Username: lzimann

Re: Proposed new rule for developers

Post by lzimann » #266528

iamgoofball wrote:what if after a feature gets added, no revert/balance PRs by anyone other than the creator for 1-3 week(s) unless said creator drops off the face of the earth during that time

i feel like that idea will lets content creators actually fine tune their work themselves instead of trying to PR their post-launch balance amid 2 revert PRs and 3 more "totally not a revert but makes it useless" prs fighting them
The problem is that the person might have a nice idea, but is horrible in balancing, giving them 3 weeks won't help in anything and might make the feature even worst.
User avatar
iamgoofball
Github User
Joined: Fri Apr 18, 2014 5:50 pm
Byond Username: Iamgoofball
Github Username: Iamgoofball

Re: Proposed new rule for developers

Post by iamgoofball » #266534

lzimann wrote:
iamgoofball wrote:what if after a feature gets added, no revert/balance PRs by anyone other than the creator for 1-3 week(s) unless said creator drops off the face of the earth during that time

i feel like that idea will lets content creators actually fine tune their work themselves instead of trying to PR their post-launch balance amid 2 revert PRs and 3 more "totally not a revert but makes it useless" prs fighting them
The problem is that the person might have a nice idea, but is horrible in balancing, giving them 3 weeks won't help in anything and might make the feature even worst.
If they want to offload it on another person it's okay, but it lets them develop their vision on their own for a little bit if they need it.
User avatar
NikNakFlak
In-Game Admin
Joined: Thu Apr 17, 2014 5:08 pm
Byond Username: NikNakflak

Re: Proposed new rule for developers

Post by NikNakFlak » #266567

A really bad idea. Bad ideas get shoehorned in sometimes and restricting who can touch it on an open source codebase even for 3 weeks is bad
User avatar
iamgoofball
Github User
Joined: Fri Apr 18, 2014 5:50 pm
Byond Username: Iamgoofball
Github Username: Iamgoofball

Re: Proposed new rule for developers

Post by iamgoofball » #266755

NikNakFlak wrote:A really bad idea. Bad ideas get shoehorned in sometimes and restricting who can touch it on an open source codebase even for 3 weeks is bad
Let's say you added a new tool for chemists. It's a little OP on launch, and you make a fix PR. Someone makes a revert PR in response to your fix/nerf PR you made, and it gets merged because it has more comments and upvotes because your fix/nerf 1. wasn't tried because all the feedback was "JUST REVERT", and 2. the revert PR has insane support because they don't want to try a fix.

How would you feel, now that a feature you worked hard on got thrown out the window even when you fixed it and they didn't even want to try the fix?
User avatar
NikNakFlak
In-Game Admin
Joined: Thu Apr 17, 2014 5:08 pm
Byond Username: NikNakflak

Re: Proposed new rule for developers

Post by NikNakFlak » #266789

That decision rests with the maintainers who ultimately decide to merge your change or completely remove the retrospective feature. I believe there's a case for that right now with the shadowshrooms deal. Do you have enough faith in your maintainers to properly give things a chance?

Are there any examples of them merging a revert instead of test merging or trying a fix/balance first?
User avatar
oranges
Code Maintainer
Joined: Tue Apr 15, 2014 9:16 pm
Byond Username: Optimumtact
Github Username: optimumtact
Location: #CHATSHITGETBANGED

Re: Proposed new rule for developers

Post by oranges » #266797

PKPenguin321 wrote:Why not let on more maintainers instead of handling 99% of the PRs by yourself, oranges?
This implies I have a choice in how many pr's I handle.

To me it seems like I wait for someone else to merge it and then the pr is open for many days, no action, I wait and I wait and then at some point I lose patience with waiting and just handle the pr
User avatar
iamgoofball
Github User
Joined: Fri Apr 18, 2014 5:50 pm
Byond Username: Iamgoofball
Github Username: Iamgoofball

Re: Proposed new rule for developers

Post by iamgoofball » #266844

NikNakFlak wrote:That decision rests with the maintainers who ultimately decide to merge your change or completely remove the retrospective feature. I believe there's a case for that right now with the shadowshrooms deal. Do you have enough faith in your maintainers to properly give things a chance?

Are there any examples of them merging a revert instead of test merging or trying a fix/balance first?
Why did you refuse to answer the question I made and go on a tangent about maintainers?
Incoming
Github User
Joined: Tue Apr 15, 2014 11:41 pm
Byond Username: Incoming
Github Username: Incoming5643

Re: Proposed new rule for developers

Post by Incoming » #266935

oranges wrote:
PKPenguin321 wrote:Why not let on more maintainers instead of handling 99% of the PRs by yourself, oranges?
This implies I have a choice in how many pr's I handle.

To me it seems like I wait for someone else to merge it and then the pr is open for many days, no action, I wait and I wait and then at some point I lose patience with waiting and just handle the pr
It's not your onus to keep the pr list short, do what your comfortable doing and if it turns out that the PR page isn't being handled by other people THEN have a discussion about needing more help. Ultimately if one person seems willing to preemptively take on extra "work" most people aren't gonna say "no, don't make my life easier!".
Developer - Datum Antags: Feburary 2016

Poly the Parrot - All Seeing Bird Transcends Universe, Joins Twitter.

Kofi - Make A Poor Life Choice

Good ideas backed by cruddy code since 2012!
User avatar
NikNakFlak
In-Game Admin
Joined: Thu Apr 17, 2014 5:08 pm
Byond Username: NikNakflak

Re: Proposed new rule for developers

Post by NikNakFlak » #266967

iamgoofball wrote:
NikNakFlak wrote:That decision rests with the maintainers who ultimately decide to merge your change or completely remove the retrospective feature. I believe there's a case for that right now with the shadowshrooms deal. Do you have enough faith in your maintainers to properly give things a chance?

Are there any examples of them merging a revert instead of test merging or trying a fix/balance first?
Why did you refuse to answer the question I made and go on a tangent about maintainers?
Because you are using a bullshit argument and a flawed question.
Let's say you added a new tool for chemists. It's a little OP on launch, and you make a fix PR. Someone makes a revert PR in response to your fix/nerf PR you made, and it gets merged because it has more comments and upvotes because your fix/nerf 1. wasn't tried because all the feedback was "JUST REVERT", and 2. the revert PR has insane support because they don't want to try a fix.

How would you feel, now that a feature you worked hard on got thrown out the window even when you fixed it and they didn't even want to try the fix?
That is my answer. I'm not going to answer your question with "yea I'd feel bad" because I A) Have never had this happen to me and B) don't see this happen in general. If honest to god a maintainer picks a revert over a balance or even worse, a PR that makes a feature work as intended, they are bad maintainers. I don't see this happening however.

Have maintainers even reverted a freshly merged feature before balance changes were attempted? Is there examples of this that you can show? Or are you just saying what-ifs in an attempt to use it as an argument. You are advocating for a "rule" about PRs which probably doesn't even need to exist because there really isn't a problem for it (unless I am mistaken and you can point out examples that I have missed.) I went on that tangent about maintainers, because in reality, they have the power to merge a fix/balance you made or revert it depending on THEIR judgement. The only difference a "3 week grace period does" is protect shitty ideas/balance changes made by the original coder instead of someone else who may be making a more reasonable balance change or even a revert. Maybe if your feature is instantly reverted instead of being balanced, you either need to take a look at the feature itself and wonder why the "big bad maintainers are out to get you and hate your feature" or that you really just suck at balance changes and people agree that someone else changes, or a revert is better. You want to shoehorn in a "policy" about code when as far as I know, doesn't even need to exist. I almost never see features instantly reverted without some sort of balance shifting first if it's new. Most of the time, maintainers and everyone spent so long arguing about something just to get it merged that they would rather see it try to get balanced before reverting. If your feature gets reverted, you must have really fucked up somewhere and any kind of "grace period" is going to change nothing.
User avatar
oranges
Code Maintainer
Joined: Tue Apr 15, 2014 9:16 pm
Byond Username: Optimumtact
Github Username: optimumtact
Location: #CHATSHITGETBANGED

Re: Proposed new rule for developers

Post by oranges » #267010

Incoming wrote:
oranges wrote:
PKPenguin321 wrote:Why not let on more maintainers instead of handling 99% of the PRs by yourself, oranges?
This implies I have a choice in how many pr's I handle.

To me it seems like I wait for someone else to merge it and then the pr is open for many days, no action, I wait and I wait and then at some point I lose patience with waiting and just handle the pr
It's not your onus to keep the pr list short, do what your comfortable doing and if it turns out that the PR page isn't being handled by other people THEN have a discussion about needing more help. Ultimately if one person seems willing to preemptively take on extra "work" most people aren't gonna say "no, don't make my life easier!".
Because it's a bad faith and rude to people who put their work on our tracker. We owe them a reasonably timely review and I feel embarrassed whenever items stay there for a long item with no activity on our part. It feels like a failure to me.
Post Reply

Who is online

Users browsing this forum: No registered users