5 ms·

> I'm not sure that's a big issue really. The repository is just a database. in large non-tech companies i see a pattern where the company adopts standard open

by shoo 7y ago

> I'm not sure that's a big issue really. The repository is just a database. in large non-tech companies i see a pattern where the company adopts standard open source tools arguably better suited to open source distributed development (many small git repos, github/gitlab) -- but then there can be pressure to present information for ease of central governance and control at $current_job there's pressure for 100-200 people to use a single jira project so auditing and risk can be done via that one jira project, whereas at the same time there are an increasing number of git repos containing code for different systems (or ci/cd/build scriptery for different systems) the jira project everyone is forced to use has about 100 different states a ticket can be in (many synonyms) and about 30 different custom relationships defined between pairs of tickets - so it is challenging to sanely encode or track the state of tickets (lowest-common-denominator meaning that it cannot be a fair approximation of the reality of an individual team's process) while also being absurdly slow. i am not quite sure what my take away is but it is completely non obvious how putting the issue tracking db in a single git repo would materially help any of this. a sufficiently entrenched bureaucracy can destroy the value of any technology...

viraptor 7y ago
> but it is completely non obvious how putting the issue tracking db in a single git repo would materially help any of this I think it could actually prevent bureaucracy from destroying the value. They can have whatever reporting, enforced flows, business states, etc that live in the repo. You get all of that info locally - so you can create a minimal, lean interface for only the small part of it that matters to you. One of the problems I had with JIRA where I used it was that it grew into a monster, even though I only needed maybe 3 functions out of it. It could be simplified from my side, but... the API was not exposed because corporate rules and the number of requests that would require to enable, made it useless to try.

by shoo 7y ago

viraptor 7y ago

> but it is completely non obvious how putting the issue tracking db in a single git repo would materially help any of this I think it could actually prevent bureaucracy from destroying the value. They can have whatever reporting, enforced flows, business states, etc that live in the repo. You get all of that info locally - so you can create a minimal, lean interface for only the small part of it that matters to you. One of the problems I had with JIRA where I used it was that it grew into a monster, even though I only needed maybe 3 functions out of it. It could be simplified from my side, but... the API was not exposed because corporate rules and the number of requests that would require to enable, made it useless to try.