Proposed new rule for developers
- oranges
- Code Maintainer
- Joined: Tue Apr 15, 2014 9:16 pm
- Byond Username: Optimumtact
- Github Username: optimumtact
- Location: #CHATSHITGETBANGED
Proposed new rule for developers
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.
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.
- 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
Sounds like a good idea honestly
- Qbopper
- Joined: Fri Jul 10, 2015 6:34 pm
- Byond Username: Qbopper
- Github Username: Qbopper
- Location: Canada
Re: Proposed new rule for developers
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
i dunno if that was ever an issue, but yeah
Limey wrote:its too late.
- Cyberboss
- Code Maintainer
- Joined: Mon Sep 26, 2016 7:58 pm
- Byond Username: Cyberboss
- Github Username: Cyberboss
- Location: Ontario, CA
- Contact:
- iamgoofball
- Github User
- Joined: Fri Apr 18, 2014 5:50 pm
- Byond Username: Iamgoofball
- Github Username: Iamgoofball
Re: Proposed new rule for developers
This is dumb
But I understand why
But I understand why
Last edited by iamgoofball on Thu Mar 09, 2017 9:56 pm, edited 1 time in total.
- 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
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.
Send me a PM if you have any issues, concerns or praise of fishfood to express about the forums.
- iamgoofball
- Github User
- Joined: Fri Apr 18, 2014 5:50 pm
- Byond Username: Iamgoofball
- Github Username: Iamgoofball
Re: Proposed new rule for developers
This tooJordie0608 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.
-
- Github User
- Joined: Tue Apr 15, 2014 11:41 pm
- Byond Username: Incoming
- Github Username: Incoming5643
Re: Proposed new rule for developers
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.
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!™
Poly the Parrot - All Seeing Bird Transcends Universe, Joins Twitter.
Kofi - Make A Poor Life Choice
Good ideas backed by cruddy code since 2012!™
- 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
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
i have three other top secret characters as well.
tell the best admin how good he is
Spoiler:
-
- Github User
- Joined: Tue Apr 15, 2014 11:41 pm
- Byond Username: Incoming
- Github Username: Incoming5643
Re: Proposed new rule for developers
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!™
Poly the Parrot - All Seeing Bird Transcends Universe, Joins Twitter.
Kofi - Make A Poor Life Choice
Good ideas backed by cruddy code since 2012!™
- 420weedscopes
- Joined: Fri Jan 02, 2015 6:52 pm
- Byond Username: 420weedscopes
- Location: Bransford, UK
- Contact:
Re: Proposed new rule for developers
wasn't this already the case for several months
have i been hot rused
have i been hot rused
Check out Phoenix Bucket!
MORE http://i.imgur.com/335AGAS.jpg
original fanart by TheWiznard http://i.imgur.com/TTd3AFt.jpgTheWiznard wrote:jmad you read a book out loud to no one for two hours
MORE http://i.imgur.com/335AGAS.jpg
- MrStonedOne
- Host
- Joined: Mon Apr 14, 2014 10:56 pm
- Byond Username: MrStonedOne
- Github Username: MrStonedOne
Re: Proposed new rule for developers
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.
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.
- 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
That adds a lot of bookkeeping overhead MrStonedOne
Besides the only people who can really delay a PR are maintainers
Besides the only people who can really delay a PR are maintainers
-
- Github User
- Joined: Tue Apr 15, 2014 11:41 pm
- Byond Username: Incoming
- Github Username: Incoming5643
Re: Proposed new rule for developers
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!™
Poly the Parrot - All Seeing Bird Transcends Universe, Joins Twitter.
Kofi - Make A Poor Life Choice
Good ideas backed by cruddy code since 2012!™
- iamgoofball
- Github User
- Joined: Fri Apr 18, 2014 5:50 pm
- Byond Username: Iamgoofball
- Github Username: Iamgoofball
Re: Proposed new rule for developers
yes but maintainers don't want to take the fall for a PR that seems unpopular because 3 people spammed 200 commentsoranges wrote:That adds a lot of bookkeeping overhead MrStonedOne
Besides the only people who can really delay a PR are maintainers
- iamgoofball
- Github User
- Joined: Fri Apr 18, 2014 5:50 pm
- Byond Username: Iamgoofball
- Github Username: Iamgoofball
Re: Proposed new rule for developers
Nope, most maintainers don't touch big feature PRs because of my above postIncoming 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.
- MisterPerson
- Board Moderator
- Joined: Tue Apr 15, 2014 4:26 pm
- Byond Username: MisterPerson
Re: Proposed new rule for developers
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
Feedback is dumb and it doesn't matter
- 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
it would also disqualify 99% of our developersform making any more changes
- 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
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.
Coder of golems, virology, hallucinations, traumas, nanites, and a bunch of miscellaneous stuff.
-
- Joined: Sat Apr 19, 2014 5:19 am
- Byond Username: Gun Hog
Re: Proposed new rule for developers
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.
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.
- NikNakFlak
- In-Game Admin
- Joined: Thu Apr 17, 2014 5:08 pm
- Byond Username: NikNakflak
Re: Proposed new rule for developers
Better than having like 5 controversial PRs open at once and have them pushing the shit PRs towards merging at all costsGun 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.
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.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.
Didn't really work out super well the last time, why would it be better any other time around? Really was just "meh" status.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.
-
- Github User
- Joined: Tue Apr 15, 2014 11:41 pm
- Byond Username: Incoming
- Github Username: Incoming5643
Re: Proposed new rule for developers
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.
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!™
Poly the Parrot - All Seeing Bird Transcends Universe, Joins Twitter.
Kofi - Make A Poor Life Choice
Good ideas backed by cruddy code since 2012!™
- 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
None of three people you mentioned are approaching anything like a reasonable merge rate to keep up the with the workload.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)..
Anturk and Razharas are the only ones who are even semi active in merging prs.
-
- Github User
- Joined: Fri Oct 14, 2016 4:55 pm
- Byond Username: Basilman
- Github Username: Militaires
Re: Proposed new rule for developers
oranges is like the ghost in spelunky
if u dont finish up quick he's gunna git ya
if u dont finish up quick he's gunna git ya
-
- Github User
- Joined: Tue Apr 15, 2014 11:41 pm
- Byond Username: Incoming
- Github Username: Incoming5643
Re: Proposed new rule for developers
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!™
Poly the Parrot - All Seeing Bird Transcends Universe, Joins Twitter.
Kofi - Make A Poor Life Choice
Good ideas backed by cruddy code since 2012!™
- 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
what do you think this thread is for
- 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
atleast I actually review.oranges wrote:None of three people you mentioned are approaching anything like a reasonable merge rate to keep up the with the workload.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)..
Anturk and Razharas are the only ones who are even semi active in merging prs.
私は完璧
-
- Github User
- Joined: Tue Apr 15, 2014 11:41 pm
- Byond Username: Incoming
- Github Username: Incoming5643
Re: Proposed new rule for developers
Well yeah that's why I brought it up. I agree with the general sentiment you're feeling here.oranges wrote:what do you think this thread is for
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!™
Poly the Parrot - All Seeing Bird Transcends Universe, Joins Twitter.
Kofi - Make A Poor Life Choice
Good ideas backed by cruddy code since 2012!™
- 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
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
gender is irrelevant NO UR IRRELEVANT
u a bish
y u heff 2 b med
-
- Joined: Fri Mar 13, 2015 10:26 pm
- Byond Username: KorPhaeron
Re: Proposed new rule for developers
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.
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.
-
- Joined: Fri Mar 13, 2015 10:26 pm
- Byond Username: KorPhaeron
Re: Proposed new rule for developers
Same rules as the feature freeze for what counts as a feature should work okay.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.
- 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
That's cool too, i just want to see you merge more pr's after you review themRemie Richards wrote:atleast I actually review.oranges wrote:None of three people you mentioned are approaching anything like a reasonable merge rate to keep up the with the workload.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)..
Anturk and Razharas are the only ones who are even semi active in merging prs.
- 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
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.
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.
私は完璧
-
- Joined: Fri Mar 13, 2015 10:26 pm
- Byond Username: KorPhaeron
Re: Proposed new rule for developers
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.
- Steelpoint
- Github User
- Joined: Thu Apr 17, 2014 6:37 pm
- Byond Username: Steelpoint
- Github Username: Steelpoint
- Location: The Armoury
-
- Code Maintainer
- Joined: Fri Apr 18, 2014 4:42 pm
- Byond Username: Anturke
Re: Proposed new rule for developers
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.
- 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
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 :^)
but in the end this would be a good change to make that stuff not happen :^)
Local catgirl scratching post - Shezza
Usually seen as Skylar Lineman/Mekhi Anderson.
Commissions way too much art...
https://tgstation13.org/phpBB/viewtopic ... 7&p=239075 - IN GAME ADMINISTRATOR
Usually seen as Skylar Lineman/Mekhi Anderson.
Commissions way too much art...
https://tgstation13.org/phpBB/viewtopic ... 7&p=239075 - IN GAME ADMINISTRATOR
NSFW:
- bandit
- Joined: Thu Apr 17, 2014 7:35 pm
- Byond Username: Bgobandit
Re: Proposed new rule for developers
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.
- 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
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.
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.
- iamgoofball
- Github User
- Joined: Fri Apr 18, 2014 5:50 pm
- Byond Username: Iamgoofball
- Github Username: Iamgoofball
Re: Proposed new rule for developers
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
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
-
- Joined: Sun Oct 26, 2014 5:13 am
- Byond Username: Lzimann
- Github Username: lzimann
Re: Proposed new rule for developers
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.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
- iamgoofball
- Github User
- Joined: Fri Apr 18, 2014 5:50 pm
- Byond Username: Iamgoofball
- Github Username: Iamgoofball
Re: Proposed new rule for developers
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.lzimann wrote: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.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
- NikNakFlak
- In-Game Admin
- Joined: Thu Apr 17, 2014 5:08 pm
- Byond Username: NikNakflak
Re: Proposed new rule for developers
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
- iamgoofball
- Github User
- Joined: Fri Apr 18, 2014 5:50 pm
- Byond Username: Iamgoofball
- Github Username: Iamgoofball
Re: Proposed new rule for developers
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.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
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?
- NikNakFlak
- In-Game Admin
- Joined: Thu Apr 17, 2014 5:08 pm
- Byond Username: NikNakflak
Re: Proposed new rule for developers
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?
Are there any examples of them merging a revert instead of test merging or trying a fix/balance first?
- 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
This implies I have a choice in how many pr's I handle.PKPenguin321 wrote:Why not let on more maintainers instead of handling 99% of the PRs by yourself, oranges?
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
- iamgoofball
- Github User
- Joined: Fri Apr 18, 2014 5:50 pm
- Byond Username: Iamgoofball
- Github Username: Iamgoofball
Re: Proposed new rule for developers
Why did you refuse to answer the question I made and go on a tangent about maintainers?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?
-
- Github User
- Joined: Tue Apr 15, 2014 11:41 pm
- Byond Username: Incoming
- Github Username: Incoming5643
Re: Proposed new rule for developers
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!".oranges wrote:This implies I have a choice in how many pr's I handle.PKPenguin321 wrote:Why not let on more maintainers instead of handling 99% of the PRs by yourself, oranges?
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
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!™
Poly the Parrot - All Seeing Bird Transcends Universe, Joins Twitter.
Kofi - Make A Poor Life Choice
Good ideas backed by cruddy code since 2012!™
- NikNakFlak
- In-Game Admin
- Joined: Thu Apr 17, 2014 5:08 pm
- Byond Username: NikNakflak
Re: Proposed new rule for developers
Because you are using a bullshit argument and a flawed question.iamgoofball wrote:Why did you refuse to answer the question I made and go on a tangent about maintainers?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?
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.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?
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.
- 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
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.Incoming wrote: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!".oranges wrote:This implies I have a choice in how many pr's I handle.PKPenguin321 wrote:Why not let on more maintainers instead of handling 99% of the PRs by yourself, oranges?
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
Who is online
Users browsing this forum: DATAxPUNGED