🆘 Please help keep this project alive - Maintainership requested!

[ghostsquad]

I think it's safe to say that neither @andygrunwald nor I use this library much, nor have the time to give it proper attention. We've also reached out to Atlassian to see if they would help by either sponsoring or providing test instances of Jira so that we could write better end-2-end tests, but that was also declined.

If anyone is interested in helping to maintain this library, including working on a v2, please let us know.

I hate seeing new issues roll in, and existing issues go stale. But I just don't have the time to work on this.

[fffinkel]

Hi there! I'm very interested in maintaining this project. I'd like to use the library for a work project, and I think it would be a great thing to get involved with. Please let me know how to proceed.

[ghostsquad]

@fffinkel - Great! I suppose there's a bit of a "test" that you should pass before getting started here, and @andygrunwald will need to actually give you access. First, please read this:

https://opensource.guide/best-practices/

and let me know what you think of each subtopic (brief brief essay)

additionally, there are a few other things that I think are important for this project:

1. strict backwards compatibility (within a major version)
2. clean git history, and conventional commits
3. documentation!

Are you familiar with these topics, and do you have prior experience in these areas? Can you point us to other projects that you are either the author of, or are maintaining? It's ok if you are new to these topics and haven't practiced them before now. I'm just asking to get a sense of history.

[ghostsquad]

additionally, it might be useful to just simply have you get started on working through some existing issues and PRs, etc. And I think that would also give a sense to how you work prior to giving you a "maintainer" role. @andygrunwald what do you think?

I don't want to put too much friction in this process, but also I think it's important to ensure there's a certain level of trust and responsibility to anyone who is a "maintainer".

[fffinkel]

I gave the best practices guide a once-over, but I'll give a thorough read tonight. Most is familiar.

Regarding the three points:

1. I have experience with this at work, where I've designed and maintained HTTP and code-level APIs. I understand the concepts and (believe I) would know how to handle such a thing if I were to begin working on a v2 for this project.
2. I am fairly experienced with git, having used it for about 10 years. I still blow my foot off from time to time but am able to fix my own with tools like the ref log. I understand concepts like branches vs tags, remotes/upstreams, merging vs rebasing, etc. My personal dotfiles project history is not great, but for projects at work I always follow common best practices for git commits: 50 char capitalized subject line, imperative mood, answering the "why," etc.
3. I'm not great at it, but I understand the importance. This project would be an opportunity for improving my skills in this arena.

I have next to no history maintaining anything open source. In the past I had a few worthless modules on Perl's CPAN, but I have since removed them. A lot of what is needed here is familiar to me because of work, but to be clear, I have no experience managing an open source project, much less one that is used.

To that end, and in response to your second message, I think that is absolutely the best way to move forward. I was afraid to ask because your request mentions a lack of time, but a perfect situation in my eyes is one where I do the work with your guidance, and you both decide when I'm ready to take over fully.

[ghostsquad]

I love the attitude!!! I'm happy to provide mentorship! That's one area that I do have time for. Maybe we can setup a voice chat sometime and I can give you a rundown of what I know, what work is needed especially with V2.

I'm on PST time. My email address is in my profile, please feel free to reach out and we can coordinate something.

[andygrunwald]

Hey Matt and Wes,
sorry to be late to the game. I agree with everything that was said here already. I would have suggested exactly the same.
I also hate it seeing unanswered PRs and issues coming in :(

Should we just start like agreed? @fffinkel if you have time and energy, just start with a few PRs or issues.
I can also provide mentorship or answering questions. Email is also visible in my profile. I am on UTC +2 // CET time.

Let us know when and how we can help. Looking forward <3

[ghostsquad]

Let's remove the stale bot for now. I think it's a bad experience given the circumstances

[fffinkel]

I've sent an email to both of you which introduces myself a bit more thoroughly and suggests a time to chat on the phone.

As you suggested, I read through the article about maintainer best practices, as well as several articles linked to in that one. If you have anything else you think I should read I'm all ears.

In an effort to get started, I have:

• Made sure go-jira tests run and pass locally
• Read through all open issues
• Read through all open pull requests

Per Wes' suggestion, I opened a pull request to disable the stale bot (#313). Any feedback is welcome!

[ghostsquad]

We likely should consider reopening recently closed issues that were closed as being stale too.

[benjivesterby]

@andygrunwald @ghostsquad I would like to help as well. A great deal of work I did at NortonLifelock (github.com/nortonlifelock/jira) used this repo and I'm going to be refactoring that work soon to PR some of it to this repo since it makes more sense to make it widely available as part of this module. I currently have a personal JIRA but I don't know if I have API access through that yet for testing.

[ghostsquad]

hi @benjivesterby ! Thanks for showing interest! @fffinkel should also be involved. Can you tell us a bit about yourself per #310 (comment) ?

[fffinkel]

Yeah!! Welcome Ben, super happy to have your help and experience!

[benjivesterby]

@ghostsquad no problem, I've contributed once to the project in the past. I'm a huge fan of the project and worked with a very large (5 million+ issue) JIRA project previously using it.

My work from NortonLifelock is open sourced here (github.com/nortonlifelock) but I do not currently maintain those projects my old team does. I do however maintain my own open source repositories which are located here (github.com/devnw).

Thank you for the link to the best practices for OSS. This will help me a lot for my own projects.

As for your points in the comment linked:

1 - strict backwards compatibility (within a major version)
This is very important. Having used this JIRA module extensively I know that any API change can drastically impact users. Breaking changes should follow the major version best practices such that any user knows what to expect. This is not only OSS best practice but also Go best practice in the community. Large issues can be seen in the GRPC and protobuf changes more recently.

2 - clean git history, and conventional commits
To be honest this is something I'm still working on but I do believe it to be important. Only more recently have I begun squashing commits all related to the same issue so that it's a singular commit. Part of this is due to personally liking the ability to back track in my own code to previous versions where I may have made an important change that I then removed. I do however understand the importance of squashed commits being PR'ed as it's much easier to manage a single commit versus N commits for a specific issue.

3 - documentation!
I believe that documentation is very important. I tend to focus on a fair amount of code documentation and forget about more README type documentation. Not because I do not believe it to be important, I just don't think about it. I also believe that with code documentation having golint be part of the pipeline helps enforce some of this behavior.

I try to follow best OSS practices with my personal OSS repos. A good indication of this is my Atomizer project (github.com/devnw/atomizer) which has a thorough set of README documentation, unit tests, github actions implementations, as well as code documentation.

Feel free to ask if there are other questions. :)

• @fffinkel

[kusuriya]

I wouldn't mind lending a hand. Per the introduction comment,
I have some experience contributing to open source here and there I wrote the initial man page for opensmtpd's sqlite database, I've done some commit updates to gitlab to improve ECS handling, and I have done some work around profiling and trying to clean up the FreeBSD build system

To the main points in the best practices for open source, it all makes sense, and boils down to a couple take aways for me. One is mentor the people behind you to replace you, the other is build a community that is ready and able to help everyone, and dont be a jerk. They are principals I like to live by and they are vital for any open source project that is going to hang around, in addition to that your additional poiints

1.) Strict Backwards Compatibility
That is basically the design of semantic versioning. you never introduce something that breaks or changes behavior as part of a patch level version, if I get 2.4.5, it needs to act like 2.4.0, full stop, no questions. if its going to change there needs to be a rev of either the minor or major number depending on how breaking the change is. Same with new features, you generally dont introduce new features at a patch level change unless its a new feature to fix an existing feature even then there is some debate on if that should be a new minor, my view is more or less it should be a new minor.

2.) Clean git history and conventional commits
Clean git history is pretty important, it makes it easier to find changes and where a bug may have been introduced, it also makes it easier to understand the flow and evolution of a project and its features. Conventional commits honestly take this a step further and blend well into using automation to generate documentation. I prefer to make my commit messages look as much like a change log as I can, especially since if It can be done reliably I can use tooling to generate reports, documentation, and other items programmatically off of it.

3.) Documentation
Your project lives, breaths, and dies on this. if people cant figure out how to use your project they will just move on, the first step in this is explaining everything in a very detailed and up to date fashion. Code is not documentation, no matter how much the bro's out there want to tell you that. Documentation is documentation and if you cant explain what you did in a concise clear manner you probably don't understand what you did yourself.

I would also add to this in all honesty code reviewing adds a ton to this and using signing off on commits is a great way to facilitate that. It makes it easier to have a second set of eyes making sure that you did what you think you did. It adds a bit of overhead but is often worth it especially if you get too wrapped up in a problem.

Either way Im going to start dredging through the open issues and see what I can repro and fix, but I figured I would register my interest here and introduce myself a little. Thanks for this library, it saved me a ton of anger for automating stuff at work.

[ghostsquad]

I would also add to this in all honesty code reviewing adds a ton to this and using signing off on commits is a great way to facilitate that.

I really like this idea, and was recently reading up on this from https://github.com/probot/dco - This would be a great addition.

I'll defer to @andygrunwald ultimately, but I don't see a problem with getting more help!! 😄

[030]

Perhaps a roadmap could be created. What are the plans regarding Jira API v3?

[ctreminiom]

I would also like to contribute too, is there a roadmap?

[yarlson]

It would be nice to start by releasing a new version, there are a lot of changes since the last one https://github.com/andygrunwald/go-jira/compare/v1.13.0..master

[benjivesterby]

Good call. I'll push one out.

[benjivesterby]

Version v1.14.0 is now available on Github

[andygrunwald]

Thanks @yarlson for the reminder and thanks @benjivesterby for execution <3

[erdvillegas]

I'm in ✋🏼, I would like to contribute with the project too, I have some experience with agile projects as a product owner practices but also i would like to perform my go skills

[manuelbcd]

me too, it would be nice to arrange something like a call together so that we could align

[Fank]

I can provide assistance, because we started to connect more and more services to jira.
And this module does look quite fitting, its just missing some stuff i would like to add.
I opened the PR #458 which is the way i would like to handle stuff for future use.
My recommendation would be a v2 with a lot of breaking changes, using proper error handling and other stuff.
So that the user is not in the need to handle the errors them self sometimes, and only return the requested object or the error if one exists, and based on errors.Is or errors.As the user can act accordingly.

In the meantime i will maintain my fork (https://github.com/mcl-de/go-jira/tree/fk_internal),
It would be nice to get some permission here soon, so i can open branches here, instead of using my fork, to be honest i am not the fan of maintaining a fork.

[andygrunwald]

Hey all,
long time silence on this one. Now there are news 📝

The news: v2 🚀

We kicked off the development of v2 🚀
I created a milestone to collect some tickets here: https://github.com/andygrunwald/go-jira/milestone/1

I described the small plan and calling for your feedback here: #489
Please check this issue and provide your feedback.

Existing issues and pull requests

We have a long backlog of open issues and pull requests.
We won't be able to work on all directly, but we will check them from time to time during the development of v2.

Contributors

Contributor wise only @benjivesterby and I right now have merge access.

We have happy to accept contributions but won't extend the round of core maintainers yet. Once, someone is providing quality PRs or useful issue triage, I am happy to chat about it.

This issue

I will close this issue for now.