# Community Visibility/Tooling

**URL:** <https://forum.getodk.org/t/community-visibility-tooling/7082>\
**Category:** Community\
**Tags:** convening-2017\
**Created:** [June 29, 2017, 6:27pm UTC](https://forum.getodk.org/t/community-visibility-tooling/7082 "2017-06-29T18:27:22Z")\
**Posts on this page:** 1\
**Showing post:** 13

<div class="post-metadata">

**Author:** ![LN](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/ln/32/1605_2.png) [@LN](https://forum.getodk.org/u/LN)\
**Post date:** [January 14, 2018, 8:54pm UTC](https://forum.getodk.org/t/community-visibility-tooling/7082/13 "2018-01-14T20:54:40Z")

</div>

Thanks for starting this conversation way back when @Jake_Watson and for reviving it @adam.butler

At the risk of restating what has already been said, here are the most pressing needs that I currently see:

- **Single landing place for developers** (both existing users and newcomers from external sources)
  - Which repo does what, what is the state of each, etc
  - Unified policies and processes (code review, style, issue triage, contributing code from a fork, who are committers, who to go to for help, etc)
  - Ongoing contexts for participating (contributor-friendly issues, Outreachy, GSoC...)
  - Priorities (roadmap)

- **Place for refined or approved user stories**
  - Forum "features" category is often raw; GitHub are more granular and include implementation strategies; where does the in-between "we know this is what need we want to satisfy but we don't know how yet" go?
  - Where does the work to refine them go?

- **Way to link related user stories**
  - e.g. there are currently several ideas in the features category that are related to accessing data outside the form ([A dynamic form data lookup locally without server synchronization](https://forum.getodk.org/t/a-dynamic-form-data-lookup-locally-without-server-synchronization/9382), [Enable Case Management/Preloading](https://forum.getodk.org/t/enable-case-management-preloading/6827)) ideally these would be formalized a bit and considered together

- **Way to track dependencies between issues** (e.g. [https://github.com/opendatakit/collect/issues/1763](https://github.com/opendatakit/collect/issues/1763) and [https://github.com/opendatakit/collect/issues/1764](https://github.com/opendatakit/collect/issues/1764))
- **Way to differentiate proposals by difficulty, importance, etc.** so they can be triaged
  - e.g. [Disable choosing an image, video or audio](https://forum.getodk.org/t/disable-choosing-an-image-video-or-audio/9338) should be really easy but there hasn't been consensus on appearance names; [Auto-gps implementation on ODK Collect](https://forum.getodk.org/t/auto-gps-implementation-on-odk-collect/10635) @Raghu_Mittal has code written for but it's stalled because the way the form specs handle this has fairly deep implications ([Spec addition proposal: location preload](https://forum.getodk.org/t/spec-addition-proposal-location-preload/10768))

Most of these needs could probably be addressed by process changes but even better if there are tools that will provide more support. I've seen Jira+Confluence used to good effect in other open source projects and haven't seen anything else I was blown away by so I'd be ready to try.

> [@adam.butler](#):
>
> In the end though, I don’t think it makes a huge amount of difference which tools you pick, as long as you commit to being serious about using them.

💯 Thank you, @adam.butler, that is a really important point.

---

_[View the full topic](https://forum.getodk.org/t/community-visibility-tooling/7082)._