| [07:49:18] | * farmBOT has joined #farmos |
| [12:42:22] | <mstenta[m]> | Curious to hear thoughts from the community on this: https://github.com/farmOS/farmOS/issues/374 |
| [13:22:39] | <paul121[m]> | mstenta: could you elaborate on this? |
| [13:22:39] | <paul121[m]> | > Drupal.org offers issue management features beyond what GitHub provides, in a way that is tailored to Drupal codebases. |
| [13:23:08] | <paul121[m]> | not advocating to get rid of Drupal issues, just curious what the specifics are |
| [14:08:58] | <mstenta[m]> | The thing I like the most about drupal.org issue queues is the way issue metadata is structured. |
| [14:10:15] | <mstenta[m]> | GitHub can do many of the same things, but not as well, IMO |
| [14:11:41] | <mstenta[m]> | In a Drupal.org issue, there are separate fields for Category, Priority, Status, Version, Component, Related issues, Parent issue, etc |
| [14:12:17] | <mstenta[m]> | GitHub's "labels" and the way it "references" other issues are very weak in comparison |
| [14:13:57] | <mstenta[m]> | Eg: I can explicitly say "these are related issues". But I can also say "these are NO LONGER related issues" and that is tracked with revisions. GitHub does not have this level of tracking, nor can you find a summary of all the issues "related to" another issue without scrolling through the whole comment feed and taking note of the little update lines mixed in |
| [14:16:10] | <mstenta[m]> | Another thing I like on Drupal.org: if an issue starts in the farmOS issue queue, but actually turns out to be an issue with an upstream module or Drupal core itself, it can easily be moved, while retaining its issue ID. (GitHub did recently add the ability to move an issue from one project to another, so that was nice. IDs do change when you do that, though) |
| [14:16:42] | <mstenta[m]> | None of these things are major points by themselves, but together they make Drupal.org better suited for Drupal module/distro development |
| [14:17:00] | <mstenta[m]> | All of them can probably be replicated in GitHub in one way or another, but not as well, IMO |
| [14:19:35] | <paul121[m]> | all good points! |
| [14:21:15] | <mstenta[m]> | Also worth mentioning... Drupal.org is using GitLab under the hood now for actual Git hosting, and allows merge requests, issue branches, etc that use GitLab |
| [14:21:37] | <paul121[m]> | seems like one distinction is that farmOS issues that pertain to the drupal core & other dependent drupal modules are best tracked on Drupal.org |
| [14:21:50] | <mstenta[m]> | Yes, that's exactly what I'm advocating... |
| [14:22:04] | <mstenta[m]> | So the question is really: where do we point people as a starting point? |
| [14:22:17] | <mstenta[m]> | Do we continue to use GitHub issue queue as a pseudo forum? |
| [14:22:24] | <mstenta[m]> | Or do we tell people to use the actual forum? |
| [14:22:36] | <mstenta[m]> | And then spin off actual issues in the relevant repositories |
| [14:22:58] | <mstenta[m]> | Most of the stuff in the GitHub issue queue is questions, bug reports, etc |
| [14:25:05] | <paul121[m]> | Seems hard to give up the low barrier-to-entry of GitHub issues |
| [14:25:25] | <mstenta[m]> | The point about "people have github accounts" is valid... but I wonder how that true is in our community? DO most of the folks that come into the farmOS community have GitHub accounts? I would say probably not. A lot do, because we attract DIY/hackers, but a lot are farmers who are not programmers |
| [14:25:32] | <paul121[m]> | thinking in terms of "do we lose community involvement if we disable GH issues?" |
| [14:25:33] | <mstenta[m]> | Yea that is the biggest selling point |
| [14:25:50] | <mstenta[m]> | > Put another way: do the benefits of having a second issue queue on GitHub outweigh the costs of managing two issue queues in parallel? |
| [14:27:11] | <mstenta[m]> | And to be clear: it hasn't been THAT big of an issue managing both. :-) |
| [14:27:35] | <mstenta[m]> | But I've definitely dreamed of collapsing the stacks :-) |
| [14:28:00] | <mstenta[m]> | And to be honest, I really do like GitHub - I make GitHub issues all the time toO! |
| [14:28:14] | <paul121[m]> | yeah. I like the idea of keeping GH issues. just afraid we'd loose out on new comers |
| [14:28:24] | <mstenta[m]> | Yea |
| [14:28:39] | <paul121[m]> | we should implement the Issue template - add a note "did you check the forum?" "is this a Drupal specific issue?" |
| [14:28:45] | <mstenta[m]> | There is definitely a middle ground... I forgot to bring up in the issue... |
| [14:29:08] | <mstenta[m]> | Yea exactly - we can just try to make it more clear that the GitHub issue queue is sort of a random dumping ground |
| [14:29:19] | <mstenta[m]> | And try to encourage using the forum more |
| [14:29:46] | <mstenta[m]> | I would also like to CLOSE as many issues as we can on GitHub |
| [14:29:54] | <mstenta[m]> | We shouldn't be leaving "discussions" open forever |
| [14:29:58] | <mstenta[m]> | That's what a forum is for |
| [14:31:12] | <mstenta[m]> | Bug reports and feature requests that don't get fixed/closed quickly should be moved to drupal.org (or other issue queues where they belong) |
| [14:31:45] | <mstenta[m]> | I don't like having to remember where an open issue is (although that's still unavoidable to some extent with multiple repositories) |
| [14:36:07] | <paul121[m]> | > Bug reports and feature requests that don't get fixed/closed quickly should be moved to drupal.org (or other issue queues where they belong) |
| [14:36:31] | <paul121[m]> | * > |
| [14:36:31] | <paul121[m]> | Bug reports and feature requests that don't get fixed/closed quickly should be moved to drupal.org (or other issue queues where they belong) |
| [14:36:31] | <paul121[m]> | just feel like non-drupal dependent issues could stay open on GH |
| [14:36:40] | <paul121[m]> | * > Bug reports and feature requests that don't get fixed/closed quickly should be moved to drupal.org (or other issue queues where they belong) |
| [14:36:40] | <paul121[m]> | just feel like non-drupal dependent issues could stay open on GH |
| [14:36:54] | <mstenta[m]> | Why not on the forum? |
| [14:37:54] | <paul121[m]> | Feature requests, yes (because that usually turns into a discussion) |
| [14:38:04] | <mstenta[m]> | If we continue to move towards building non-Drupal code in other repositories (like farmOS-map and farmOS-client), then farmOS's codebase really is MOSTLY Drupal |
| [14:38:24] | <paul121[m]> | bug a bug report pertaining to farmOS logic? hmm. idk |
| [14:38:29] | <paul121[m]> | yes that is true |
| [14:38:58] | <mstenta[m]> | I'm not opposed to bug reports - assuming they are ones that get closed quickly |
| [14:40:56] | <mstenta[m]> | I agree the forum isn't a great place for bug reports (although users are already posting them there too) |
| [14:41:00] | <mstenta[m]> | But ideally a bug ISSUE is more specific than a bug REPORT |
| [14:41:59] | <paul121[m]> | true. we shouldn't discourage bugs from being reported anywhere! |
| [14:42:18] | <mstenta[m]> | agreed |
| [14:42:57] | <paul121[m]> | speaking of... I think I found a bug. Where should I post? :P |
| [14:42:59] | <paul121[m]> | ACTION uploaded an image: vocab_link_bug.png (40KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/yupIrtAjdrSYxVTd... > |
| [14:43:06] | <mstenta[m]> | haha |
| [14:43:15] | <paul121[m]> | the `vocabulary.uri` link is not valid |
| [14:44:18] | <paul121[m]> | maybe its possible to have a page for taxonomy vocabularies? but farmOS doesn't provide one? |
| [14:44:47] | <mstenta[m]> | this is in 1.x, right? |
| [14:44:53] | <paul121[m]> | yes |
| [14:44:59] | <mstenta[m]> | is it a `restws` issue? or something coming from `farm_api`? |
| [14:45:12] | <mstenta[m]> | looks like `restws`? |
| [14:45:54] | <paul121[m]> | I'm not sure! |
| [14:46:12] | <paul121[m]> | this snippet is from `localhost/taxonomy_term.json` - likely restws? |
| [14:46:21] | <mstenta[m]> | yea |
| [14:46:30] | <mstenta[m]> | i don't think we do anything to alter that |
| [14:47:21] | <mstenta[m]> | (taking this as an example, if it were posted to github I would close it and tell you to open a new issue in drupal.org. if it were posted to drupal.org, i would move it myself to restws project) |
| [14:48:16] | <mstenta[m]> | > I would close it and tell you to open a new issue in drupal.org |
| [14:48:16] | <mstenta[m]> | (specifically in the `restws` issue queue, not farmOS's) |
| [14:48:58] | <paul121[m]> | gotcha |
| [14:50:07] | <mstenta[m]> | (or i dunno, maybe i would open the issue myself on behalf of farmOS... because "it's not our fault but it is our problem" - but it is more work for me to open a new issue than to move one) |
| [14:51:01] | <mstenta[m]> | but... on the other hand... if someone reported a map bug in the farmOS GitHub queue, it would be easy for me to move that to farmOS-map... so this distinction is neither here nor there perhapos |
| [14:51:07] | <mstenta[m]> | * but... on the other hand... if someone reported a map bug in the farmOS GitHub queue, it would be easy for me to move that to farmOS-map... so this distinction is neither here nor there perhaps |
| [14:52:17] | <mstenta[m]> | I did some digging into past discussions in the Drupal community about moving to GitHub/GitLab... here are a few links worth posting here for future reference: |
| [14:52:26] | <mstenta[m]> | https://www.drupal.org/drupalorg/docs/gitlab-integration/gitlab-frequent... |
| [14:52:34] | <mstenta[m]> | https://www.drupal.org/drupalorg/blog/developer-tools-initiative-part-2-... |
| [14:52:51] | <mstenta[m]> | https://www.drupal.org/project/drupalorg/issues/2205815 |
| [14:52:57] | <mstenta[m]> | https://groups.drupal.org/node/313068 |
| [14:53:20] | <paul121[m]> | yea. its good to have the paper trail that an issue was "discovered" in farmOS, even though its not our fault. for various reasons |
| [14:53:40] | <mstenta[m]> | yup |
| [14:53:50] | <mstenta[m]> | https://www.drupal.org/project/drush/issues/1761910#comment-7587019 |
