Joe, I find this excellent suggestions. We should definitely follow up on them as they could be a selling point for other Apache or ML centric projects. Sadly though I am not sure how useful they would be outside of open source (Apache) communities as I have not observed ML centric commercial projects before.
Peter On 16 March 2013 17:51, Joe Dreimann <[email protected]> wrote: > 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 >
