Suggestion Spigot Pull Request Committee

Discussion in 'Community Feedback and Suggestions' started by DiamondDagger590, Apr 13, 2021.

  1. Atlassian BitBucket is pretty stupid when it comes to user-related automation, and I think this is out of the question. However, I do agree with Shane's approach.
    [​IMG]
    I'm not really sure how the permission system works, but you can easily tell how limited it is. "Admin, Write, Read"[​IMG]
     
    #21 Martoph, Apr 14, 2021
    Last edited: Apr 14, 2021
  2. Choco

    Moderator

    FTFY

    If we used anything other than Stash I think it would be more reasonable but at that point, if we weren't using Stash... we wouldn't have this issue to begin with :rolleyes: I don't think it has any form of automation whatsoever outside of the Bitbucket pipelines and even those are meh.
     
    • Funny Funny x 1
  3. What’s stopping us from moving away from this to a better software alternative? Even if it takes 2 weeks to do so for example, I say the benefits of expanded permissions outweigh the the time cost in the long run and addresses the largest point people have brought up: the CLA
     
  4. Choco

    Moderator

    Integration and ensuring history are two of the most important things. Integration with the JIRA (because dropping JIRA and its history definitely is not an option) and guaranteeing that active (or even closed) pull requests aren't deleted.
     
  5. Do you know if any research into what a conversion to another platform would look like? I agree those are all required, just didn’t know if it was looked into and not possible or not looked into much etc
     
  6. Andre_601

    Supporter

    PaPEr iS BeTTEr tHaN SpEiGOT! Yo StoOpid!1!ii!

    (Bad jokes aside, this is a well made feedback. A pleasure for my eyes)
     
    • Like Like x 1
  7. Isn't Stash/Atlassian just a front end for git? Can a separate tool or web page be made that uses git to retrieve the pull requests so people can review them? That would allow public access without changing the current tools that do the real work.
     
  8. can't they get rid of stash and use github? since paper does it without a problem.
     
  9. Choco

    Moderator

    • Informative Informative x 1
  10. but paper isn't effected by this since they have code on github wouldn't project get dmca taken down?
     
  11. I think you're deviating from the thread's purpose. This isn't meant to be a "why can paper do this but we can't" thread
     
    • Agree Agree x 1
  12. Just a bump on this as I am generally curious as to what the answer would be.

    I think this is the main end goal with what I hope to accomplish. CLA aside (which I believe the thread as a whole has more or less agreed needs addressed in some regard), increasing communication and speed is something I really hope to accomplish.

    So I guess let's consider what qualifications would quantify someone as "PR team material". In my opinion, it should be someone who has in the last 2-3 months done at least 3 pull requests. One of these pull requests at least should be a substantial one, being more than exposing a method, changing visibility of a field etc. Prime example being adding a new event or exposing new parts of the API (such as the outstanding Structure PR). 2-3 months is a good time frame to allow for people to work on quality pull requests and to give ample time for changes and so forth in my opinion but I am open to suggestions as with everything else on what others may think.

    There should be some sort of activity requirement for this team, although what that would look like is a lot more of a gray area imo. What happens if they get busy with work or uni and can only comment on pull requests? The criteria of getting to *be* on the team helps show they have a decent amount of experience and commitment to the project. But obviously if someone goes MIA for months, there isn't much reason to keep them on the team. Thoughts on things like this would be much appreciated
     
  13. Eh, should be longer and more consistent. I've been making somewhat consistent PRs for almost a year now. (Not even that many tbh).
    I agree there should be more than just exposing methods/adding events. Creating new API for some internal mechanism, supporting capabilities that vanilla may've offered but spigot didn't (ahem... https://hub.spigotmc.org/stash/projects/SPIGOT/repos/craftbukkit/pull-requests/815/overview), and maybe a few bug fixes would all count towards someone's eligibility.
    But should there really be set concrete rules? No, I don't think so. md, along with others, can tell who is developer/pr team material just based on the quality of their commits and history. Are they professional? Do they defend their coding decisions when pressed? Are they afraid to disagree? In my mind, a team like this could be setup similar to an application process that staff have where occasionally there's the opportunity to apply and get accepted based on md's (and whoever's) discretion.

    Concrete eligibility can lead to a flood of poorly written PRs due to many people (especially younger) wanting the clout of a developer tag appear next to their name. People will flood the PR gates because they believe they have what it takes. As far as activity goes, I think that's just up to md's discretion. Time around big updates and snapshots may require a lot more activity than other times. Also, what was your personal idea in terms of size of this team? I was thinking between 3-7 people along with md. (not that it matters, just wanted your opinion)
     
    • Agree Agree x 1
    • Useful Useful x 1
  14. Andre_601

    Supporter

    Paper is NOT SpigotMC.
    SpigotMC got a DMCA because a dev claimed some of the code used being his without approval from him (which is debatable on various levels) while PaperMC is implementing their own patches without really using that particular code (I at least believe this is kind of the reason here)
     
  15. You make some very good points which I really don’t have any issues with myself tbh. Said application process would also likely make things easier in the long run to maintain on md’s end.

    Overall team size 3-7 is a really good balance. Not too many where there’s a lot of disagreement to the point it lacks constructiveness, but just the right amount to have *someone* respond to PR’s within 24 hours at most usually
     
  16. I completely agree the backlog on the stash system is enormous because no one cleans it out. Also in my opinion someone should investigate if a data transfer to another platform is possible we cannot loose any of our issues and PR thats just a no go. Bottom line is we need more people with authorization to make changes into the code base because currently MD is the only one with write permissions on spigot what would we do if he decided to stop suddenly or something else terrible happens to him. An open source project like this cannot and should not be ran solely by 1 person would it like to survive.
     
    • Agree Agree x 1