I am so sorry, but I have deleted the question by mistake . Let's see, if there is any help: https://answers.atlassian.com/questions/11455582
Trying to reproduce the helpful answers from today:
When does it make sense to use JIRA with Confluence? What is your experience?
thats a good question, and i´m interested about other peoples experience, too.
We use Confluence mostly as standalone (not that much linking between JIRA and Confluence i would say)
As mostly not means at all, our developers use Confluence to document their process, use it for meeting notes, planning and share about everthing during the process with their colleagues, to document all you have to write down, everthing you to wrote down in the past on papers actually. The sharing of information that way is a big effort. Mistakes at the beginning of the project are fater discovered, as many people can have a look on it.
We dont use the full potencial between Confluence and JIRA and for JIRA itself, at the moment.
I can share some uses we make, there are probably much more out there.
Both systems alone have their usecases and works great, but the strength comes with the good integration of both systems and their similar Look and Feel.
We use JIRA as classical "Issue Management System" for software development and Confluence for documentation. So we have Issues in JIRA, which we can document in Confluence. The otherway round we use the JIRA macro in Confluence to create a review document for example.
Ferenc Kiss [Midori]
They co-exist brilliantly.
We usually approach the question does this type of information fits JIRA or Confluence better? by viewing the "nature" of the data. If it is unstructured (textual, visual), then it goes to Confluence, if it is structured (typed fields, strong workflow, reporting needs), then it goes to JIRA. And then, there is various ways to build links between the two systems.
My thought on this question is if the nature of the information is "static" or "dynamic" (in lack of better terms). I think JIRA works well for dynamic information, in the sense that it is relevant for work in progress. It is of course also helpful to revisit the information if there is an issue with it later, but hopefully this is never needed once the issue is closed.
Confluence complements by providing static information, for example documentation that is read frequently and is not related to one particular issue. It can be requirements for the product, user guides, tool information and so on. I use it for information that is useful over time as opposed to information needed for a specific job.
Paul Pasler in reply to Eirik Midttun
I would not fully agree with this. Confluence content should also be organic and dynamic, in my opinion there is nothing more annoying in a Wiki than legacy content. We also use JIRA for Tasks that need to be done anytime in the future, so we don't forget them.
Eirik Midttun in reply to Paul Pasler
I'm not saying Confluence should not be updated, which is why I have some doubt of the term static. Maybe it is better to call it "stable"? Maybe this explains it better: - Information needed for doing specific work -> JIRA - Information guiding or explaining the work (more generally) -> Confluence
You have a lot of good feedback's in here, I personally agree with most of andrew's answers. Regarding the user management it depends, if you want to organize your groups on LDAP/AD then go with connecting Confluence And JIRA directly into LDAP/AD.
If you prefer to manage the groups locally and only pull the users from LDAP/AD then it will depends how you manage your applications, If you have a team that manages confluence and other that manages JIRA you can use the same logic as above, if you have a single team to manage the access of both apps, go with Connect JIRA on LDAP/AD and then connect confluence in JIRA.
From the support perspective I usually see huge instances connecting separately and small/medium connecting JIRA on LDAP/AD and then Confluence on JIRA.
One thing I can tell you for sure, never use the read and write option in the user directory configuration because if you do that all info updated on the user base in confluence/JIRA will reflect on LDAP/AD and depending on what a end user does (let's say a end user with admin privileges) you could end up with a account deleted by mistake.
I'll jump in, as I didn't see our exact uses mentioned yet.
Many of our processes originate in JIRA, and Confluence is the best way for us to tie them all together and put everything from documentation to task statuses, milestones (using Team Calendars to further visualize things like Sprints or project milestones), etc.
Hopefully that helps
As I've learned from Atlassian Sales:
You are only evaluating the product now, so you benefit from the maximal user tier. If you decide to purchase the product, we'll generate a quote for you at the user tier you need. Please note that your Confluence does not need to match the user tier of your JIRA License.
That was good news.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG