From 9a8e09d25907659caaf5ef96286e1bb326706b06 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Samuel=20G=C3=A9lineau?= Date: Tue, 4 Oct 2016 08:04:45 -0400 Subject: [PATCH] remove references to Jira from the wiki according to 3b49b2465cb28ce9877c250c7e64b3795292e93c, issues are now handled in the github issue tracker of each repository, so those bits were outdated. --- wiki/faq.md | 13 ------------- wiki/maintainers.md | 4 ++-- 2 files changed, 2 insertions(+), 15 deletions(-) diff --git a/wiki/faq.md b/wiki/faq.md index ffcd8d3..321475f 100644 --- a/wiki/faq.md +++ b/wiki/faq.md @@ -19,19 +19,6 @@ there are still gaps. You can find them via the *resources* tab just above this page. -#### Will I have to register a Jira account to submit issues? - -Yes, you will need to provide a name and email address. - -#### Why are you using Jira instead of Github Issues? It seems more complicated. - -Jira **is** a bit more complicated than github's bug tracker, and it's certainly -not perfect. It is, however, a lot better suited to managing and planning a -project of this size. Cloud Haskell consists of no less than **13** individual -projects at this time, and that's not to mention some of the experimental ones -that have been developed by community members and *might* end up being absorbed -by the team. - ### Help If the documentation doesn't answer your question, queries about Cloud Haskell diff --git a/wiki/maintainers.md b/wiki/maintainers.md index 72e563d..d565456 100644 --- a/wiki/maintainers.md +++ b/wiki/maintainers.md @@ -11,7 +11,7 @@ process and in particular, the branching strategy. We also point out Cloud Haske various bits of infrastructure as they stand at the moment. Perhaps the most important thing to do as a maintainer, is to make other developers -aware of what you're working on by assigning the Jira issue to yourself! +aware of what you're working on by assigning the github issue to yourself! ---- #### Releases @@ -132,7 +132,7 @@ you've finished and uploaded the release. If you build and tag three projects, only to find that a subsequent dependent package needs a bit of last minute surgery, you'll be sorry you didn't wait. With that in mind.... -Before releasing any source code, make sure that all the jira tickets +Before releasing any source code, make sure that all the github tickets added to the release are either resolved or remove them from the release if you've decided to exclude them.