So it turns out that open source projects like ours are eligible for completely free, unlimited access to all Atlassian applications, which includes JIRA, Bitbucket, Confluence, etc. etc.
Given this, I've thought of a few reasons why it might be good for us to move our various source control, wiki and issue tracking solutions into one (professional quality...) stack, since it'll cost us nothing:
- There is a new major release of SMF (the forum software we use) coming up, which is almost guaranteed to break the Project Tools mod we use for issue tracking. I am a JIRA administrator in my day job, and I think it would be a very good alternative. It would also allow give us tools to plan, which is something we currently lack. We could also offer these services to people for game development purposes.
- Bitbucket can import GitHub repos with only a few clicks, including the full history. It also integrates with JIRA, allowing you to tag commits with the issue that's being addressed (whether it's a bug fix or a feature request / story). The learning curve would be very small for current users of the AGS GitHub repos.
- The AGS Wiki is pretty poorly maintained atm. It could be if we move that over to Confluence things'll improve. It certainly won't get any worse!
I've signed up for a trial of JIRA, with an example issue here (https://adventuregamestudio.atlassian.net/secure/RapidBoard.jspa?rapidView=1&projectKey=AE&selectedIssue=AE-1). This issue shows how it integrates with the AGS Bitbucket (https://bitbucket.org/adventuregamestudio/ags) trial, where I've committed a 'fix' to a reported issue. To gain access, all anyone will need to do is create a free Atlassian account (https://id.atlassian.com). We can of course limit the ability to push to the repos or administer the JIRA projects as required if we decide to go ahead; all Atlassian require is the software be publically accessible.
So what do we think?
I use Jira on my day job for projects, I like it but I am curious if everything can be made public and easily indexed by Google - Jira search is pretty awful in my experience, even with all tagging options. Confluence is pretty cool and I ported old docx texts to it using pandoc with relatively good success. Bitbucket I am not sure if it allows multi user open source - for free. Atlassian also owns Trello.
Public access is doable. Or at least 'if you have an Atlassian account, you're in' level of public. I'm not sure why extensive search is really necessary though. JIRA is quite visual, so you don't really need to search too hard to find stuff. Especially not with the small scale we'd probably have...
*Everything* Atlassian related is free if you have an open source project, including third party plugins. The only actual requirement is it be publically accessible. As such, we could definitely replace GitHub with Bitbucket.
I'll have to get up to speed on Jira+Confluence for work, so for me it would work out. :P
The user side is pretty straightforward. If you know about Scrum or Kanban boards you basically have the gist already.
We use the Atlassian stack at my job, and I'm not a fan.
Jira in particular is maybe my most hated software on the planet: yes, it's very powerful, but it also too complex and unintuitive. I remember on the first day using it, I sent them about 5 tickets about various usability issues (buttons are not where you'd expect them, extra clicks needed for basic stuff, etc), I didn't get any replies (i suspect that the feedback button leads to nowhere).
BitBucket is mostly ok, but it's slightly less appealing than Github. For one thing, the ecosystem around Github seems friendlier: integrating Travis for example with Github was a snap, but integrating Jenkins with BitBucket was a nightmare (and also I don't think Bamboo is free for open source). You can tag issues in commits in Github as well, btw. But perhaps the best argument for sticking with Github is visibility: it's the most popular option, most developers are familiar with it and there's an organic stream of new developers interested in the project that I don't think we'll get with Bitbucket.
As for confluence and project management, Github has both a wiki and a project management tool which we can use (the functionality might be more basic, but it's also more friendly, and good enough for our needs, I believe).
I'm curious what the JIRA setup looks like at your work. I was the one who set it up where I work, and I find it very intuitive and easy to use... (yeah, I would say that...). Did you look at the Cloud instance I linked though? It's very streamlined and clean compared to the full server version.
What about if you think about Bitbucket for our actual needs though? I can't imagine we actually need CI, for instance. I also wonder just how much this organic stream of new developers you mention has actually ever happened, or is that just a theoretical? I thought all the engine/editor contributors so far got involved through the community, rather than just stumbling across the code?
Do people use the AGS GitHub for anything except source control? If it can management stuff that's good, but is it used at all? Having those tools front and center on the site and forums might help encourage their use (whether it's GitHub or Atlassian...).
Quote from: AGA on Wed 20/12/2017 18:03:14
I can't imagine we actually need CI, for instance.
When Nick Sonneveld set up automatic build server and auto tests, it felt like a heavy slab was lifted from me, because I no longer had to test pull requests manually to see if everything compiles and runs. It also showed if ports still compile, which was invaluable, since not everyone can build all of them on their working place.
People could even download results of their pull requests compilation in the form of full AGS package, which made it much easier to distribute WIP features for testing.
Quote from: AGA on Wed 20/12/2017 18:03:14
Do people use the AGS GitHub for anything except source control?
Issue tracker was used extensively over years, port issues were mainly reported there over time.
We used Github wiki to write few articles about the code structure, because it was more convenient to have them near the repository.
Okay, fair enough. Bitbucket would integrate with a Bamboo or Jenkins instance (Bamboo being free, even if the hosting would need to be arranged somewhere) if that's what we need.
I don't think we would lose any functionality overall. With a bit of effort (which I'm willing to do), we could clone the current setup almost 1:1. I'm just wondering whether having a more complete toolset might actually help with some of the problems AGS development faces.
Regardless of anything else, a replacement for Project Tools needs to be found soon, since as I say it's at the end of its life.
Oh, apparently CI is built in to Bitbucket cloud, so no Bamboo or Jenkins setup required: https://bitbucket.org/product/features/pipelines.
I feel that github and bitbucket functionality for source control is equal but I agree that the community around github is better. The issue tracker in github seems sufficient for issues. The only tool I feel would trully add is confluence, and AFAIK we could use confluence without moving the source to Bitbucket, essentially getting the best of both worlds, assuming the confluence wiki can be exposed for Google.
Quote from: AGA on Wed 20/12/2017 18:03:14
I'm curious what the JIRA setup looks like at your work. I was the one who set it up where I work, and I find it very intuitive and easy to use... (yeah, I would say that...). Did you look at the Cloud instance I linked though? It's very streamlined and clean compared to the full server version.
Oh, wow. This looks much better than what we have at the office. Now I wonder if the on-premise version is really that different or we're just using a really old version.
Anyway, even with the new interface, it still seems overly complicated, and here's an example for something not intuitive at all. I navigated a bit and went back to the issues and all of a sudden the issue disappeared. Apparently there's 2 tabs for issues? Here's one without the issue (https://bitbucket.org/adventuregamestudio/ags/issues) and here's the one with the issue (https://adventuregamestudio.atlassian.net/projects/AE/issues/AE-1?filter=allissues).
Classic Jira/Atlassian confusion :-\
Quote
I thought all the engine/editor contributors so far got involved through the community, rather than just stumbling across the code?
It's hard to say for sure, because people might use completely different nicknames, but if I look at the list of the people who forked AGS (https://github.com/adventuregamestudio/ags/network/members) (i.e a partial list of the people who made an attempt of doing something with the code) there are a lot of names I don't recognize from the forums.
JIRA server looks very different from Cloud. But how your server instance is administered does make a big difference too. Also JIRA is more then ten years old, and can be used for free forever if you don't renew your 'maintenence licence' (upgrade eligibility), so it could also be your work has an old version!
That was a configuration issue. I have only spent half an hour looking at this yet; I wanted to gauge potential interest before wasting too much time on it. Bitbucket Cloud has its own built in issue tracking feature, which is what you were seeing on https://bitbucket.org/adventuregamestudio/ags/issues. I have now turned that off, with the assumption issues would be logged in JIRA. JIRA is supposed to be the driving force here, so you can do some limited Bitbucket stuff (creating branches and viewing related commits), but issues should be created and viewed in JIRA rather than in Bitbucket. Bitbucket commits are then tagged with one or more JIRA issue IDs, which links them. It might not be 100% intuitive, but it works perfectly once you get used to it!
I wonder how many of those forkers (tee hee) have actually committed anything though? And how many of them just stumbled across the source without having come via the website and forums. There's nothing stopping someone from creating a fork or branch in Bitbucket rather than GitHub, if we set up the access right.
Unless there are substantial complaints with our current setup at Github, I'm not in favor of moving to a new one. Migrations always turn out more complicated than they first seem, and it would mean a large amount of effort for not a lot of benefit.
I also think it would be best to stick with GitHub for the moment. It is still not clear what the direction of future development is, so it will be pretty difficult to predict that development, wiki, manual, or issue tracking will be improved by a change in tooling. In terms of SMF Project Tools, I don't know if someone was trying to keep the technical issues opened there in sync with the GitHub issue tracker, but to me it would seem more straightforward for technical issues to go to GitHub and script help issues to be covered by forum help (I imagine anyone offering help in the forum would probably be okay with having a Github account and using it to reference a forum post, if a problem needed to be raised as a technical issue).
Why?
I'm in favour using GitHub for bug tracking, going forward.
In my opinion, dealing with the imminent retirement of the project tools is not about selecting the appropriate tool. GitHub is adequate for our needs. The only thing that needs to be done is a migration of the old bugs that are open to GitHub or an export of old bugs in some read-only format. Both of these sound like hard things to do. It's much easier to discuss yet another ancillary bug tracking system, it seems.
Last time we talked about bug tracking tools, it was mentioned that signing up for a GitHub account might be a stumbling block. I don't see it. So many open-source projects use GitHub now, it's not funny. It is the de facto standard.
I just had a peek at the test JIRA project and it is similar enough to the JIRA deployment I'm forced to use at work that it made me shudder. Regardless of how much they dress it up, I still find JIRA user-hostile.
Quote from: Gurok on Thu 11/01/2018 00:41:02
Last time we talked about bug tracking tools, it was mentioned that signing up for a GitHub account might be a stumbling block.
In regards to this, I'm currently developing a GitHub app which would at a later stage after initial release support a way for people to create issues on a repo without needing any type of account.
I personally agree I don't see having to create a GitHub account as an issue for most folks, but there are probably a few people who would prefer NOT to create one so my app could potentially be of use :)
Either way, Project Tools has to go, very soon. I'm happy to try to import the outstanding issues, if someone can give me appropriate access levels on the repo. GH username is berianwilliams.
Quote from: AGA on Sat 20/01/2018 13:39:18
Either way, Project Tools has to go, very soon. I'm happy to try to import the outstanding issues, if someone can give me appropriate access levels on the repo. GH username is berianwilliams.
I was very scared of this in the past, because there are lots of opened issues which may not be relevant anymore (because engine has changed). But if it has to happen, then I guess there is no save from that.
Would it be possible to add certain label to the imported issues, something to distinct them, so that devs could easily find them? For example "from ags tracker".
I will give you access level soon.
Sure, I'll make it clear they were imported from PT.
Question: what kind of access permissions do you need for this?
Issues may be created by anyone. Labels - not sure.
I think we'll need to use REST/SOAP to do this. Does that need to be turn on, or access granted, or is it accessible by default?
Got the access, thanks. I'll try to work out how to handle the importing soon.