Moving Collect issues to Collect repo

Development
1

Hi all,

Given the changes coming down the line for the project, I'd like to
make things easier for contributors by moving the issues from the
project wide repo (https://github.com/opendatakit/opendatakit) to the
Collect repo (https://github.com/opendatakit/collect).

I think the current issues structure is a remnant of the move from
Google Code and it makes it unnecessarily complicated for people who
just care about Collect to track what needs fixing and update issues
when they are fixed.

Per the (brand-new!) governance guidelines at
https://github.com/opendatakit/governance/blob/master/GOVERNANCE.md#decision-making-process,
what does everyone think? Should we move the issues?

Yaw

2

Hello Yaw,

I believe this loosely relates to the question I asked recently about pull
requests:
https://groups.google.com/d/topic/opendatakit-developers/6i6i1PShYJs/discussion.

TL;DR - Yes, splitting the issues out probably will make issue management
simpler and more intuitive for those not already familiar with the existing
scheme.

··· ---

Since I have not been working with the system myself, I can't pretend to
know all of the ramifications of such a move. However, I can say that the
way that issues are managed does make it somewhat more opaque than the
average GitHub project. What you suggest is more intuitive and aligns with
the tooling (and conventions) naturally. The existing system could work
with more documentation and organizational discipline, but in my opinion it
highlights the reason it is less than ideal: it needs more explanation and
discipline to make sense.

Splitting the issues out has its own trade-offs, probably the biggest one
being coordinating issues/release milestones between projects. However,
from what I understand about the design of Collect, Aggregate and friends,
they are stand-alone applications that should make sense on their own.
Having to align on project releases is probably an indication that things
are too brittle. Instead, these dependencies should be explicit in a
protocol version or equivalent, and both should depend on the protocol
version not on each other. When there are related issues, it often is
helpful to voice them in terms of the project as well - so creating a
Collect issue and referencing a related issues in Aggregate makes sense.
You'll ultimately have to make changes in both projects, having two issues
actually mirrors the work needing to be done.

With what I understand about the design of the suite, I think this makes
more sense. It also is what most GitHub users would expect to see.

Brent

On Tuesday, August 23, 2016 at 7:57:00 AM UTC-4, Yaw Anokwa wrote:

Hi all,

Given the changes coming down the line for the project, I'd like to
make things easier for contributors by moving the issues from the
project wide repo (https://github.com/opendatakit/opendatakit) to the
Collect repo (https://github.com/opendatakit/collect).

I think the current issues structure is a remnant of the move from
Google Code and it makes it unnecessarily complicated for people who
just care about Collect to track what needs fixing and update issues
when they are fixed.

Per the (brand-new!) governance guidelines at

https://github.com/opendatakit/governance/blob/master/GOVERNANCE.md#decision-making-process,

what does everyone think? Should we move the issues?

Yaw

3

I agree with this change.

As a semi-regular peruser of github projects, I would never think to browse
a separate repo for issues relating to a particular app.

I've seen projects with new issues that are pre-populated with text, which
I've seen to suggest issue structure (summary, steps to reproduce, expected
behavior, etc). One could imagine a note about contributing to a different
URL or to the contributing guidelines. This still wouldn't be especially
natural in my opinion, however.

For changes that do matter across components, a components project sibling
to collect and friends could have an issue tracker that supports
discussion. "Consider migration to component-foo 1.3" or something could be
opened on the Collect Issue tracker with a link back to the general
discussion, so users of only a single app would still be aware of the
discussion.

In general, though, I wholeheartedly agree with Brent. If commits across
repos have to be highly coordinated, things are likely too brittle. If
necessary, however, and if the continuous integration idea
https://groups.google.com/forum/#!topic/opendatakit-developers/raj3OVlc9aA
becomes a reality, it might be possible to point at particular versions of
an artifact and reduce the need for coordinated releases.

··· On Tue, Aug 23, 2016 at 7:41 AM, Brent Atkinson wrote:

Hello Yaw,

I believe this loosely relates to the question I asked recently about pull
requests: https://groups.google.com/d/topic/opendatakit-developers/
6i6i1PShYJs/discussion.

TL;DR - Yes, splitting the issues out probably will make issue management
simpler and more intuitive for those not already familiar with the existing
scheme.

Since I have not been working with the system myself, I can't pretend to
know all of the ramifications of such a move. However, I can say that the
way that issues are managed does make it somewhat more opaque than the
average GitHub project. What you suggest is more intuitive and aligns with
the tooling (and conventions) naturally. The existing system could work
with more documentation and organizational discipline, but in my opinion it
highlights the reason it is less than ideal: it needs more explanation and
discipline to make sense.

Splitting the issues out has its own trade-offs, probably the biggest one
being coordinating issues/release milestones between projects. However,
from what I understand about the design of Collect, Aggregate and friends,
they are stand-alone applications that should make sense on their own.
Having to align on project releases is probably an indication that things
are too brittle. Instead, these dependencies should be explicit in a
protocol version or equivalent, and both should depend on the protocol
version not on each other. When there are related issues, it often is
helpful to voice them in terms of the project as well - so creating a
Collect issue and referencing a related issues in Aggregate makes sense.
You'll ultimately have to make changes in both projects, having two issues
actually mirrors the work needing to be done.

With what I understand about the design of the suite, I think this makes
more sense. It also is what most GitHub users would expect to see.

Brent

On Tuesday, August 23, 2016 at 7:57:00 AM UTC-4, Yaw Anokwa wrote:

Hi all,

Given the changes coming down the line for the project, I'd like to
make things easier for contributors by moving the issues from the
project wide repo (https://github.com/opendatakit/opendatakit) to the
Collect repo (https://github.com/opendatakit/collect).

I think the current issues structure is a remnant of the move from
Google Code and it makes it unnecessarily complicated for people who
just care about Collect to track what needs fixing and update issues
when they are fixed.

Per the (brand-new!) governance guidelines at
https://github.com/opendatakit/governance/blob/master/
GOVERNANCE.md#decision-making-process,
what does everyone think? Should we move the issues?

Yaw

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

1 Like
4

Yaw,

That sounds extremely sensible.

However, for issues that span multiple components, what would be the plan?
Have related issues, one in each appropriate repo?

In our JIRA system, we had a bunch of different projects and then we
recently merged down to a single project with component tags for the
individual components. That was a lot easier when it came to dashboards,
assignments, releases, etc. (Though, in our case, releases are always
coordinated across all components. Since ODK often releases components
separately, the single-project, shared-releases approach maybe makes less
sense.)

Best,

Chris

··· On Tue, Aug 23, 2016 at 7:57 AM Yaw Anokwa wrote:

Hi all,

Given the changes coming down the line for the project, I'd like to
make things easier for contributors by moving the issues from the
project wide repo (https://github.com/opendatakit/opendatakit) to the
Collect repo (https://github.com/opendatakit/collect).

I think the current issues structure is a remnant of the move from
Google Code and it makes it unnecessarily complicated for people who
just care about Collect to track what needs fixing and update issues
when they are fixed.

Per the (brand-new!) governance guidelines at

https://github.com/opendatakit/governance/blob/master/GOVERNANCE.md#decision-making-process
,
what does everyone think? Should we move the issues?

Yaw

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

5

I'm strongly for issues in their repo. I understand the value of what
Christopher is proposing. I think especially with Collect their will be
groups interested in just contributing to that. Having to parse through
issues for say aggregate would add a lot of complexity if you are not well
versed in both. Github issues are by nature simple which I think works
well for a project like this vis-a-vis jira which is more powerful but
complex.

··· On Aug 23, 2016 12:06 PM, "Sam Sudar" wrote:

I agree with this change.

As a semi-regular peruser of github projects, I would never think to
browse a separate repo for issues relating to a particular app.

I've seen projects with new issues that are pre-populated with text, which
I've seen to suggest issue structure (summary, steps to reproduce, expected
behavior, etc). One could imagine a note about contributing to a different
URL or to the contributing guidelines. This still wouldn't be especially
natural in my opinion, however.

For changes that do matter across components, a components project sibling
to collect and friends could have an issue tracker that supports
discussion. "Consider migration to component-foo 1.3" or something could be
opened on the Collect Issue tracker with a link back to the general
discussion, so users of only a single app would still be aware of the
discussion.

In general, though, I wholeheartedly agree with Brent. If commits across
repos have to be highly coordinated, things are likely too brittle. If
necessary, however, and if the continuous integration idea
https://groups.google.com/forum/#!topic/opendatakit-developers/raj3OVlc9aA
becomes a reality, it might be possible to point at particular versions of
an artifact and reduce the need for coordinated releases.

On Tue, Aug 23, 2016 at 7:41 AM, Brent Atkinson brent.atkinson@gmail.com wrote:

Hello Yaw,

I believe this loosely relates to the question I asked recently about
pull requests: https://groups.google.com/d/to
pic/opendatakit-developers/6i6i1PShYJs/discussion.

TL;DR - Yes, splitting the issues out probably will make issue management
simpler and more intuitive for those not already familiar with the existing
scheme.

Since I have not been working with the system myself, I can't pretend to
know all of the ramifications of such a move. However, I can say that the
way that issues are managed does make it somewhat more opaque than the
average GitHub project. What you suggest is more intuitive and aligns with
the tooling (and conventions) naturally. The existing system could work
with more documentation and organizational discipline, but in my opinion it
highlights the reason it is less than ideal: it needs more explanation and
discipline to make sense.

Splitting the issues out has its own trade-offs, probably the biggest one
being coordinating issues/release milestones between projects. However,
from what I understand about the design of Collect, Aggregate and friends,
they are stand-alone applications that should make sense on their own.
Having to align on project releases is probably an indication that things
are too brittle. Instead, these dependencies should be explicit in a
protocol version or equivalent, and both should depend on the protocol
version not on each other. When there are related issues, it often is
helpful to voice them in terms of the project as well - so creating a
Collect issue and referencing a related issues in Aggregate makes sense.
You'll ultimately have to make changes in both projects, having two issues
actually mirrors the work needing to be done.

With what I understand about the design of the suite, I think this makes
more sense. It also is what most GitHub users would expect to see.

Brent

On Tuesday, August 23, 2016 at 7:57:00 AM UTC-4, Yaw Anokwa wrote:

Hi all,

Given the changes coming down the line for the project, I'd like to
make things easier for contributors by moving the issues from the
project wide repo (https://github.com/opendatakit/opendatakit) to the
Collect repo (https://github.com/opendatakit/collect).

I think the current issues structure is a remnant of the move from
Google Code and it makes it unnecessarily complicated for people who
just care about Collect to track what needs fixing and update issues
when they are fixed.

Per the (brand-new!) governance guidelines at
https://github.com/opendatakit/governance/blob/master/GOVERN
ANCE.md#decision-making-process,
what does everyone think? Should we move the issues?

Yaw

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

6

Hey Yaw,

Im in favor of the issues on the individual repos. My understanding of github design for issues is that they are directly related to the code base of the repo and its branches... I think it also makes more sense for all the other ODK products (aggregate, briefcase etc.) as they are developed separately and should have seperate feature/issues tracking... I think all are in consensus.

Do you think it would be worth doing a initial walk through of the issues to consolidate and set priorities to start working on them. Im ready :)..

Jon

··· On Tuesday, August 23, 2016 at 7:57:00 AM UTC-4, Yaw Anokwa wrote: > Hi all, > > Given the changes coming down the line for the project, I'd like to > make things easier for contributors by moving the issues from the > project wide repo (https://github.com/opendatakit/opendatakit) to the > Collect repo (https://github.com/opendatakit/collect). > > I think the current issues structure is a remnant of the move from > Google Code and it makes it unnecessarily complicated for people who > just care about Collect to track what needs fixing and update issues > when they are fixed. > > Per the (brand-new!) governance guidelines at > https://github.com/opendatakit/governance/blob/master/GOVERNANCE.md#decision-making-process, > what does everyone think? Should we move the issues? > > Yaw
7

Sounds like we have consensus.

Who would like to take the lead on making this happen?

··· On Tue, Aug 23, 2016 at 10:49 PM, Matt Berg wrote: > I'm strongly for issues in their repo. I understand the value of what > Christopher is proposing. I think especially with Collect their will be > groups interested in just contributing to that. Having to parse through > issues for say aggregate would add a lot of complexity if you are not well > versed in both. Github issues are by nature simple which I think works > well for a project like this vis-a-vis jira which is more powerful but > complex. > > > On Aug 23, 2016 12:06 PM, "Sam Sudar" wrote: >> >> I agree with this change. >> >> As a semi-regular peruser of github projects, I would never think to >> browse a separate repo for issues relating to a particular app. >> >> I've seen projects with new issues that are pre-populated with text, which >> I've seen to suggest issue structure (summary, steps to reproduce, expected >> behavior, etc). One could imagine a note about contributing to a different >> URL or to the contributing guidelines. This still wouldn't be especially >> natural in my opinion, however. >> >> For changes that do matter across components, a components project sibling >> to collect and friends could have an issue tracker that supports discussion. >> "Consider migration to component-foo 1.3" or something could be opened on >> the Collect Issue tracker with a link back to the general discussion, so >> users of only a single app would still be aware of the discussion. >> >> In general, though, I wholeheartedly agree with Brent. If commits across >> repos have to be highly coordinated, things are likely too brittle. If >> necessary, however, and if the continuous integration idea becomes a >> reality, it might be possible to point at particular versions of an artifact >> and reduce the need for coordinated releases. >> >> >> >> On Tue, Aug 23, 2016 at 7:41 AM, Brent Atkinson wrote: >>> >>> Hello Yaw, >>> >>> I believe this loosely relates to the question I asked recently about >>> pull requests: >>> https://groups.google.com/d/topic/opendatakit-developers/6i6i1PShYJs/discussion. >>> >>> TL;DR - Yes, splitting the issues out probably will make issue management >>> simpler and more intuitive for those not already familiar with the existing >>> scheme. >>> >>> --- >>> >>> Since I have not been working with the system myself, I can't pretend to >>> know all of the ramifications of such a move. However, I can say that the >>> way that issues are managed does make it somewhat more opaque than the >>> average GitHub project. What you suggest is more intuitive and aligns with >>> the tooling (and conventions) naturally. The existing system could work with >>> more documentation and organizational discipline, but in my opinion it >>> highlights the reason it is less than ideal: it needs more explanation and >>> discipline to make sense. >>> >>> Splitting the issues out has its own trade-offs, probably the biggest one >>> being coordinating issues/release milestones between projects. However, from >>> what I understand about the design of Collect, Aggregate and friends, they >>> are stand-alone applications that should make sense on their own. Having to >>> align on project releases is probably an indication that things are too >>> brittle. Instead, these dependencies should be explicit in a protocol >>> version or equivalent, and both should depend on the protocol version not on >>> each other. When there are related issues, it often is helpful to voice them >>> in terms of the project as well - so creating a Collect issue and >>> referencing a related issues in Aggregate makes sense. You'll ultimately >>> have to make changes in both projects, having two issues actually mirrors >>> the work needing to be done. >>> >>> With what I understand about the design of the suite, I think this makes >>> more sense. It also is what most GitHub users would expect to see. >>> >>> Brent >>> >>> On Tuesday, August 23, 2016 at 7:57:00 AM UTC-4, Yaw Anokwa wrote: >>>> >>>> Hi all, >>>> >>>> Given the changes coming down the line for the project, I'd like to >>>> make things easier for contributors by moving the issues from the >>>> project wide repo (https://github.com/opendatakit/opendatakit) to the >>>> Collect repo (https://github.com/opendatakit/collect). >>>> >>>> I think the current issues structure is a remnant of the move from >>>> Google Code and it makes it unnecessarily complicated for people who >>>> just care about Collect to track what needs fixing and update issues >>>> when they are fixed. >>>> >>>> Per the (brand-new!) governance guidelines at >>>> >>>> https://github.com/opendatakit/governance/blob/master/GOVERNANCE.md#decision-making-process, >>>> what does everyone think? Should we move the issues? >>>> >>>> Yaw >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "ODK Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to opendatakit-developers+unsubscribe@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "ODK Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to opendatakit-developers+unsubscribe@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "ODK Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to opendatakit-developers+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout.
8

Sorry for the delay, folks. There's a lot going on!

You can now find the list of committers and PMC in the governance
docs. Thanks for the suggestion, Lindsay.
Commiters: https://github.com/opendatakit/governance/blob/master/GOVERNANCE.md#current-committers
PMC: https://github.com/opendatakit/governance/blob/master/GOVERNANCE.md#current-project-management-committee

As far as who moves the issues, I think it was a mistake on my part to
open that up to volunteers. The 'you have to earn commit privileges'
is a core principle of the meritocracy we are trying to build, and we
should only bypass that privilege when we have no other choice. Since
I suggested the move, I've gone ahead and started to move the issues.
I expect that work will be done in a few hours.

I do think it'd be very useful for us to triage the issues, Jon. How
about we start with the lowest ID defects and try to reproduce them?
If we can, great. If not, those get closed and we go from there.
Anyone besides Jon interested in helping to triage the issues tagged
as defects?

Yaw

··· -- Need ODK consultants? Nafundi provides form design, server setup, in-field training, and software development for ODK. Go to https://nafundi.com to get started.

On Thu, Sep 1, 2016 at 7:52 PM, jon@geomarvel.com wrote:

On Tuesday, August 23, 2016 at 7:57:00 AM UTC-4, Yaw Anokwa wrote:

Hi all,

Given the changes coming down the line for the project, I'd like to
make things easier for contributors by moving the issues from the
project wide repo (https://github.com/opendatakit/opendatakit) to the
Collect repo (https://github.com/opendatakit/collect).

I think the current issues structure is a remnant of the move from
Google Code and it makes it unnecessarily complicated for people who
just care about Collect to track what needs fixing and update issues
when they are fixed.

Per the (brand-new!) governance guidelines at
https://github.com/opendatakit/governance/blob/master/GOVERNANCE.md#decision-making-process,
what does everyone think? Should we move the issues?

Yaw

Hey Yaw,

Im in favor of the issues on the individual repos. My understanding of github design for issues is that they are directly related to the code base of the repo and its branches... I think it also makes more sense for all the other ODK products (aggregate, briefcase etc.) as they are developed separately and should have seperate feature/issues tracking... I think all are in consensus.

Do you think it would be worth doing a initial walk through of the issues to consolidate and set priorities to start working on them. Im ready :)..

Jon

--
You received this message because you are subscribed to the Google Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

9

Hi Yaw,

It sounds very reasonable to me. Cross-referencing issues from other repos works well, so I don't think any functionality is lost in doing that.

There seems to be a few scripts kicking around for migrating issues between repos that could be used. I'm willing to give it a shot, if you don't mind giving me permissions on the repos to do that.

My question about the governance is whether it's currently known who the various position holders are, or would most likely be? Perhaps it would be worth considering posting this info in the governance repo? Possibly also whether or not the members of the PMC and committers groups are being sponsored or supported by some institution or business for their time to do that role, or if it's in their own time, so as to credit that donation to the future of the project.

Best regards,
Lindsay

10

Hi All,

Github just added quite a few new features, including basic project
management (kind of like Trello, Zenhub, or Jira boards, though very
basic). They haven't yet solved the problem that issues and "projects" are
tied to a single repository. So the current solution (Collect issues living
in the Collect repo) seems to make sense. But it might be interesting to
use their "cards" implementation of issues to organize them.

You can read more about the new features here:

Regards,
Jeff

··· On Mon, Sep 5, 2016 at 9:56 AM, Yaw Anokwa wrote:

Sorry for the delay, folks. There's a lot going on!

You can now find the list of committers and PMC in the governance
docs. Thanks for the suggestion, Lindsay.
Commiters: https://github.com/opendatakit/governance/blob/
master/GOVERNANCE.md#current-committers
PMC: https://github.com/opendatakit/governance/blob/
master/GOVERNANCE.md#current-project-management-committee

As far as who moves the issues, I think it was a mistake on my part to
open that up to volunteers. The 'you have to earn commit privileges'
is a core principle of the meritocracy we are trying to build, and we
should only bypass that privilege when we have no other choice. Since
I suggested the move, I've gone ahead and started to move the issues.
I expect that work will be done in a few hours.

I do think it'd be very useful for us to triage the issues, Jon. How
about we start with the lowest ID defects and try to reproduce them?
If we can, great. If not, those get closed and we go from there.
Anyone besides Jon interested in helping to triage the issues tagged
as defects?

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Thu, Sep 1, 2016 at 7:52 PM, jon@geomarvel.com wrote:

On Tuesday, August 23, 2016 at 7:57:00 AM UTC-4, Yaw Anokwa wrote:

Hi all,

Given the changes coming down the line for the project, I'd like to
make things easier for contributors by moving the issues from the
project wide repo (https://github.com/opendatakit/opendatakit) to the
Collect repo (https://github.com/opendatakit/collect).

I think the current issues structure is a remnant of the move from
Google Code and it makes it unnecessarily complicated for people who
just care about Collect to track what needs fixing and update issues
when they are fixed.

Per the (brand-new!) governance guidelines at
https://github.com/opendatakit/governance/blob/
master/GOVERNANCE.md#decision-making-process,
what does everyone think? Should we move the issues?

Yaw

Hey Yaw,

Im in favor of the issues on the individual repos. My understanding of
github design for issues is that they are directly related to the code base
of the repo and its branches... I think it also makes more sense for all
the other ODK products (aggregate, briefcase etc.) as they are developed
separately and should have seperate feature/issues tracking... I think all
are in consensus.

Do you think it would be worth doing a initial walk through of the
issues to consolidate and set priorities to start working on them. Im ready
:)..

Jon

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

11

Hi Yaw,

I am willing to help try and reproduce defects myself. How do I ensure I'm
not duplicating effort by working on the same issue? Can I assign them to
myself if I'm not an org or project member?

Brent

··· On Mon, Sep 5, 2016 at 12:56 PM, Yaw Anokwa wrote:

Sorry for the delay, folks. There's a lot going on!

You can now find the list of committers and PMC in the governance
docs. Thanks for the suggestion, Lindsay.
Commiters: https://github.com/opendatakit/governance/blob/
master/GOVERNANCE.md#current-committers
PMC: https://github.com/opendatakit/governance/blob/
master/GOVERNANCE.md#current-project-management-committee

As far as who moves the issues, I think it was a mistake on my part to
open that up to volunteers. The 'you have to earn commit privileges'
is a core principle of the meritocracy we are trying to build, and we
should only bypass that privilege when we have no other choice. Since
I suggested the move, I've gone ahead and started to move the issues.
I expect that work will be done in a few hours.

I do think it'd be very useful for us to triage the issues, Jon. How
about we start with the lowest ID defects and try to reproduce them?
If we can, great. If not, those get closed and we go from there.
Anyone besides Jon interested in helping to triage the issues tagged
as defects?

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Thu, Sep 1, 2016 at 7:52 PM, jon@geomarvel.com wrote:

On Tuesday, August 23, 2016 at 7:57:00 AM UTC-4, Yaw Anokwa wrote:

Hi all,

Given the changes coming down the line for the project, I'd like to
make things easier for contributors by moving the issues from the
project wide repo (https://github.com/opendatakit/opendatakit) to the
Collect repo (https://github.com/opendatakit/collect).

I think the current issues structure is a remnant of the move from
Google Code and it makes it unnecessarily complicated for people who
just care about Collect to track what needs fixing and update issues
when they are fixed.

Per the (brand-new!) governance guidelines at
https://github.com/opendatakit/governance/blob/
master/GOVERNANCE.md#decision-making-process,
what does everyone think? Should we move the issues?

Yaw

Hey Yaw,

Im in favor of the issues on the individual repos. My understanding of
github design for issues is that they are directly related to the code base
of the repo and its branches... I think it also makes more sense for all
the other ODK products (aggregate, briefcase etc.) as they are developed
separately and should have seperate feature/issues tracking... I think all
are in consensus.

Do you think it would be worth doing a initial walk through of the
issues to consolidate and set priorities to start working on them. Im ready
:)..

Jon

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

12

Hey Brent,

I don't think Github lets you assign to non-project members.

I'd optimize for lightweight for now. Comment on the issue you are
working on, and go from there.

Yaw

··· On Thu, Sep 15, 2016 at 8:43 PM, Brent Atkinson wrote: > Hi Yaw, > > I am willing to help try and reproduce defects myself. How do I ensure I'm > not duplicating effort by working on the same issue? Can I assign them to > myself if I'm not an org or project member? > > Brent > > On Mon, Sep 5, 2016 at 12:56 PM, Yaw Anokwa wrote: >> >> Sorry for the delay, folks. There's a lot going on! >> >> You can now find the list of committers and PMC in the governance >> docs. Thanks for the suggestion, Lindsay. >> Commiters: >> https://github.com/opendatakit/governance/blob/master/GOVERNANCE.md#current-committers >> PMC: >> https://github.com/opendatakit/governance/blob/master/GOVERNANCE.md#current-project-management-committee >> >> As far as who moves the issues, I think it was a mistake on my part to >> open that up to volunteers. The 'you have to earn commit privileges' >> is a core principle of the meritocracy we are trying to build, and we >> should only bypass that privilege when we have no other choice. Since >> I suggested the move, I've gone ahead and started to move the issues. >> I expect that work will be done in a few hours. >> >> I do think it'd be very useful for us to triage the issues, Jon. How >> about we start with the lowest ID defects and try to reproduce them? >> If we can, great. If not, those get closed and we go from there. >> Anyone besides Jon interested in helping to triage the issues tagged >> as defects? >> >> Yaw >> -- >> Need ODK consultants? Nafundi provides form design, server setup, >> in-field training, and software development for ODK. Go to >> https://nafundi.com to get started. >> >> On Thu, Sep 1, 2016 at 7:52 PM, wrote: >> > On Tuesday, August 23, 2016 at 7:57:00 AM UTC-4, Yaw Anokwa wrote: >> >> Hi all, >> >> >> >> Given the changes coming down the line for the project, I'd like to >> >> make things easier for contributors by moving the issues from the >> >> project wide repo (https://github.com/opendatakit/opendatakit) to the >> >> Collect repo (https://github.com/opendatakit/collect). >> >> >> >> I think the current issues structure is a remnant of the move from >> >> Google Code and it makes it unnecessarily complicated for people who >> >> just care about Collect to track what needs fixing and update issues >> >> when they are fixed. >> >> >> >> Per the (brand-new!) governance guidelines at >> >> >> >> https://github.com/opendatakit/governance/blob/master/GOVERNANCE.md#decision-making-process, >> >> what does everyone think? Should we move the issues? >> >> >> >> Yaw >> > >> > Hey Yaw, >> > >> > Im in favor of the issues on the individual repos. My understanding of >> > github design for issues is that they are directly related to the code base >> > of the repo and its branches... I think it also makes more sense for all the >> > other ODK products (aggregate, briefcase etc.) as they are developed >> > separately and should have seperate feature/issues tracking... I think all >> > are in consensus. >> > >> > Do you think it would be worth doing a initial walk through of the >> > issues to consolidate and set priorities to start working on them. Im ready >> > :).. >> > >> > Jon >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "ODK Developers" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> > an email to opendatakit-developers+unsubscribe@googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "ODK Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to opendatakit-developers+unsubscribe@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "ODK Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to opendatakit-developers+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout.
13

And to make things a little easier. I've used a help-wanted tag
(https://github.com/opendatakit/collect/labels/help%20wanted) on the
issues that I think would be good to start from. When you start
working on one, leave a comment, so we know someone is working on
them!

··· On Fri, Sep 16, 2016 at 12:29 PM, Yaw Anokwa wrote: > Hey Brent, > > I don't think Github lets you assign to non-project members. > > I'd optimize for lightweight for now. Comment on the issue you are > working on, and go from there. > > Yaw > > On Thu, Sep 15, 2016 at 8:43 PM, Brent Atkinson wrote: >> Hi Yaw, >> >> I am willing to help try and reproduce defects myself. How do I ensure I'm >> not duplicating effort by working on the same issue? Can I assign them to >> myself if I'm not an org or project member? >> >> Brent >> >> On Mon, Sep 5, 2016 at 12:56 PM, Yaw Anokwa wrote: >>> >>> Sorry for the delay, folks. There's a lot going on! >>> >>> You can now find the list of committers and PMC in the governance >>> docs. Thanks for the suggestion, Lindsay. >>> Commiters: >>> https://github.com/opendatakit/governance/blob/master/GOVERNANCE.md#current-committers >>> PMC: >>> https://github.com/opendatakit/governance/blob/master/GOVERNANCE.md#current-project-management-committee >>> >>> As far as who moves the issues, I think it was a mistake on my part to >>> open that up to volunteers. The 'you have to earn commit privileges' >>> is a core principle of the meritocracy we are trying to build, and we >>> should only bypass that privilege when we have no other choice. Since >>> I suggested the move, I've gone ahead and started to move the issues. >>> I expect that work will be done in a few hours. >>> >>> I do think it'd be very useful for us to triage the issues, Jon. How >>> about we start with the lowest ID defects and try to reproduce them? >>> If we can, great. If not, those get closed and we go from there. >>> Anyone besides Jon interested in helping to triage the issues tagged >>> as defects? >>> >>> Yaw >>> -- >>> Need ODK consultants? Nafundi provides form design, server setup, >>> in-field training, and software development for ODK. Go to >>> https://nafundi.com to get started. >>> >>> On Thu, Sep 1, 2016 at 7:52 PM, wrote: >>> > On Tuesday, August 23, 2016 at 7:57:00 AM UTC-4, Yaw Anokwa wrote: >>> >> Hi all, >>> >> >>> >> Given the changes coming down the line for the project, I'd like to >>> >> make things easier for contributors by moving the issues from the >>> >> project wide repo (https://github.com/opendatakit/opendatakit) to the >>> >> Collect repo (https://github.com/opendatakit/collect). >>> >> >>> >> I think the current issues structure is a remnant of the move from >>> >> Google Code and it makes it unnecessarily complicated for people who >>> >> just care about Collect to track what needs fixing and update issues >>> >> when they are fixed. >>> >> >>> >> Per the (brand-new!) governance guidelines at >>> >> >>> >> https://github.com/opendatakit/governance/blob/master/GOVERNANCE.md#decision-making-process, >>> >> what does everyone think? Should we move the issues? >>> >> >>> >> Yaw >>> > >>> > Hey Yaw, >>> > >>> > Im in favor of the issues on the individual repos. My understanding of >>> > github design for issues is that they are directly related to the code base >>> > of the repo and its branches... I think it also makes more sense for all the >>> > other ODK products (aggregate, briefcase etc.) as they are developed >>> > separately and should have seperate feature/issues tracking... I think all >>> > are in consensus. >>> > >>> > Do you think it would be worth doing a initial walk through of the >>> > issues to consolidate and set priorities to start working on them. Im ready >>> > :).. >>> > >>> > Jon >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> > Groups "ODK Developers" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> > an email to opendatakit-developers+unsubscribe@googlegroups.com. >>> > For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "ODK Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to opendatakit-developers+unsubscribe@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "ODK Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to opendatakit-developers+unsubscribe@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout.
14

Hi Yaw,

Thank you. The tags helped to make the issues of interest easier to
identify.

Anyone interested in helping still should be careful since it may not be
obvious when not to consider them, since non-members can not update the
status or tags. More specifically, anyone considering these should take
note of comments after when the 'help-wanted' tag was added for its status.
For example, I just confirmed and submitted a pull request for #197
https://github.com/opendatakit/collect/issues/197, but it will still be
labeled 'help-wanted' until someone does something with it.

Just a heads-up.

Regards,

Brent

··· On Fri, Sep 16, 2016 at 8:43 AM, Yaw Anokwa wrote:

And to make things a little easier. I've used a help-wanted tag
(https://github.com/opendatakit/collect/labels/help%20wanted) on the
issues that I think would be good to start from. When you start
working on one, leave a comment, so we know someone is working on
them!

On Fri, Sep 16, 2016 at 12:29 PM, Yaw Anokwa yanokwa@nafundi.com wrote:

Hey Brent,

I don't think Github lets you assign to non-project members.

I'd optimize for lightweight for now. Comment on the issue you are
working on, and go from there.

Yaw

On Thu, Sep 15, 2016 at 8:43 PM, Brent Atkinson brent.atkinson@gmail.com wrote:

Hi Yaw,

I am willing to help try and reproduce defects myself. How do I ensure
I'm
not duplicating effort by working on the same issue? Can I assign them
to
myself if I'm not an org or project member?

Brent

On Mon, Sep 5, 2016 at 12:56 PM, Yaw Anokwa yanokwa@nafundi.com wrote:

Sorry for the delay, folks. There's a lot going on!

You can now find the list of committers and PMC in the governance
docs. Thanks for the suggestion, Lindsay.
Commiters:
https://github.com/opendatakit/governance/blob/
master/GOVERNANCE.md#current-committers
PMC:
https://github.com/opendatakit/governance/blob/
master/GOVERNANCE.md#current-project-management-committee

As far as who moves the issues, I think it was a mistake on my part to
open that up to volunteers. The 'you have to earn commit privileges'
is a core principle of the meritocracy we are trying to build, and we
should only bypass that privilege when we have no other choice. Since
I suggested the move, I've gone ahead and started to move the issues.
I expect that work will be done in a few hours.

I do think it'd be very useful for us to triage the issues, Jon. How
about we start with the lowest ID defects and try to reproduce them?
If we can, great. If not, those get closed and we go from there.
Anyone besides Jon interested in helping to triage the issues tagged
as defects?

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Thu, Sep 1, 2016 at 7:52 PM, jon@geomarvel.com wrote:

On Tuesday, August 23, 2016 at 7:57:00 AM UTC-4, Yaw Anokwa wrote:

Hi all,

Given the changes coming down the line for the project, I'd like to
make things easier for contributors by moving the issues from the
project wide repo (https://github.com/opendatakit/opendatakit) to
the
Collect repo (https://github.com/opendatakit/collect).

I think the current issues structure is a remnant of the move from
Google Code and it makes it unnecessarily complicated for people who
just care about Collect to track what needs fixing and update issues
when they are fixed.

Per the (brand-new!) governance guidelines at

https://github.com/opendatakit/governance/blob/
master/GOVERNANCE.md#decision-making-process,
what does everyone think? Should we move the issues?

Yaw

Hey Yaw,

Im in favor of the issues on the individual repos. My understanding
of
github design for issues is that they are directly related to the
code base
of the repo and its branches... I think it also makes more sense for
all the
other ODK products (aggregate, briefcase etc.) as they are developed
separately and should have seperate feature/issues tracking... I
think all
are in consensus.

Do you think it would be worth doing a initial walk through of the
issues to consolidate and set priorities to start working on them.
Im ready
:)..

Jon

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.