Ryan is spot on here I think. I would like to think that we are welcoming to people who are not comfortable committing everything to the codebase, because their suggestions can still be valuable contributions. That's not wooly feel good talk but an approach to encourage contributions.
By definition everyone that contributes here believes that issue trackers add value, so arguing against using our own may be a big turnoff to contributors. Greg and Brane you are highlighting some important problems with issue tracking software in general though, like the complete separation between information in issue trackers and the codebase. I believe we should try and address these issues in Apache Bloodhound instead of accepting them as a fact and working around them ourselves. Part of the value of dogfooding, like we are doing, is to feel these pain points and then do something about them. If Bloodhound deals with them better than other issue trackers we're probably on to a winner. So, what can we do? - Expose TODOs found in the source code comments in the Bloodhound UI, which should help people discovering them and developers being more comfortable to not also raise a ticket - Show relevant mailing list discussions on tickets, this may drive more discussing to the mailing list without the annoyance painful search in 3rd party hosted archives to refer to emails - Close tickets or comment on them via commit messages, removing the need to go back to the bloodhound UI to do so. - Improve the search in source code (that would have helped me add an inline comment) - Allow adding comments to the source code via the bloodhound UI (not code mind you) Some of these are no doubt bad ideas, but I would challenge you to come up with better ways to reduce the overhead an issue tracker introduces and improve it further instead of arguing we should essentially stop using it. - Joe ________________________ @jdreimann - Twitter Sent from my phone On 16 Mar 2013, at 08:44, Greg Stein <[email protected]> wrote: > How about leaving some TODO markers in the page via commit? Maybe > somebody will follow up on that commit, and actually make the changes. > > Why should the marker be within a ticket, instead of the codebase > itself? Again, if somebody goes to fix this, then they have > double-work: make some commits, and make some ticket changes. > > The ticket system is entirely divorced from the codebase. Consider: > community members can spend the next month handling tickets. Does that > accomplish anything? Nope. Alternative: work within the actual > product, making changes/notes as they are discovered. > > Cheers, > -g > > > On Fri, Mar 15, 2013 at 12:11 PM, Apache Bloodhound > <[email protected]> wrote: >> #467: About page should include a link to Apache Bloodhound >> --------------------------+--------------- >> Reporter: jdreimann | Owner: >> Type: enhancement | Status: new >> Priority: major | Version: >> Resolution: | >> --------------------------+--------------- >> https://bh-demo1.apache.org/about >> Currently contains plenty of links to trac, but no links to any Bloodhound >> pages. >> >> Also, the Footer shows: >> "Visit Apache Bloodhound at https://issues.apache.org/bloodhound/"; - I >> think it should be "Get involved in [Apache Bloodhound]" and the [name] >> should be a link to our site. >> >> -- >> Ticket URL: <https://issues.apache.org/bloodhound/ticket/467> >> Apache Bloodhound <https://issues.apache.org/bloodhound/> >> The Apache Bloodhound (incubating) issue tracker
