Issues about issues #51
Comments
|
Tools designed for open ended and exploratory discussion like Discourse or
Slack or Discord come to mind. Sometimes the bits are free, sometimes not.
Usually hosting is required.
The closest thing that comes to mind is to continue to use GitHub issues,
but open the dialog there. By the time code is written, usually a
discussion is moot. Coordination should happen before code is written and
merged.
Engaging collaborators can happen via many channels. Understanding their
incentives, origins, and experience is key. And something beyond GitHub.
Dave McClure's Pirate Metrics is a reference to a user funnel worth
consideration.
Also, I'm not sure I see a use case for issues that don't close.
Long term items can live in the roadmap. Active issues can be issues.
Juggling too much is akin to too much data in RAM. Multitasking is a myth.
I've also seen Google docs or similar for outlining long term product ideas.
Overall, I'm conciously trying to increase focus and limit scope.
Expansive thinking is effortless, but creates implicit obligations I'd
prefer to avoid. I think about the lifecycle from idea to implementation.
Some ideas must die on the vine. Not all ideas are worth tending to, given
limited resources.
Happy to keep this dialogue open.
…On Sun, Jul 1, 2018, 14:08 Theo Armour ***@***.***> wrote:
Story
@afomi <https://github.com/afomi>
See #31 <#31>
Issues drive Pull Requests. Visible communication happens as a byproduct.
++ the previous text
I very much hear you.
What you describe is a process analogous to the operation of a well-oiled
machine. In such operations all parties know where they belong and what
they are meant to do. I very much hope we get to such a level before too
long.
But we are not there yet. We have few players. And, as far as this player
is concerned, he knows not yet where he belongs or what are the good things
to do.
My questions include: how can we in a free, open source manner do the
following?
- Create at least a few highly open-ended discussions. Not looking for
closing issues. But, metaphorically, looking for openings
- Invent ways of informing newbs that there there is an active,
dynamic, friendly community that welcomes new players
- And instill a drive to innovate, break down barriers and help peeps
live better
What do we do with issues that may take a long time to close or even that
we may never want to close but keep redefining? And how can do all this
using GitHub or something similar?
My own explorations into this include using GitHub pages as blog posts,
mucking around with Gists and more. None of these have the email follow
through, markdown support and more that GitHub issues provides. So hacking
GitHub issues seems natural to me, but I understand it a may well be odd
behavior for others.
So I am very open to discussing ways of discussing very open ended
discussions using open source tools. ;-)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#51>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEJkDM-dHTdMLDTobYWcROl_dwFEPWvks5uCTpNgaJpZM4U-eDa>
.
|
Communications
Much more could be said about the above, but GitHub - coders writing for other coders is quite special. If you are a coder. Pirate Metricshttp://500hats.typepad.com/500blogs/2007/09/startup-metrics.html Focus and scopeLet's focus and limit scope. You specify. I build. Then you build. Repeat until finished. What code does opentecture need to get the the next stage? |
|
Hi @theo-armour, The bits of Discourse can be free. Hosting then costs money. Sounds like you want to talk in Forums or a Mailing List. Nevertheless, for a dialogue, start an Issue (prior to writing code) - develop the dialogue there (this is a natural part of the lifecycle of a Feature Request), let the idea evolve, and hopefully at some point, the Issue can be re-cast into a clearly defined scope of work that delivers concrete user value. Regarding Focus and Scope - I set out to to clean up Issues that cannot be completed. I have shared User Stories describing the value of proposed Features, and Acceptance Criteria attempting to clarify the user experience desired - Acceptance Criteria is also pseudo-code for automated tests. Sounds like a meeting will be helpful to increase clarity and focus on the backlog of Issues. I parsed out many comments in your GraphQL Issue into discrete Issues that can be tackled one at a time. Let's find a time to chat soon. |
|
@theo-armour - just for reference, but I thought this was timely - https://drewdevault.com/2018/07/02/Email-driven-git.html |
Story
@afomi
See #31
I very much hear you.
What you describe is a process analogous to the operation of a well-oiled machine. In such operations all parties know where they belong and what they are meant to do. I very much hope we get to such a level before too long.
But we are not there yet. We have few players. And, as far as this player is concerned, he knows not yet where he belongs or what are the good things to do.
My questions include: how can we in a free, open source manner do the following?
What do we do with issues that may take a long time to close or even that we may never want to close but keep redefining? And how can do all this using GitHub or something similar?
My own explorations into this include using GitHub pages as blog posts, mucking around with Gists and more. None of these have the email follow through, markdown support and more that GitHub issues provides. So hacking GitHub issues seems natural to me, but I understand it a may well be odd behavior for others.
So I am very open to discussing ways of discussing very open ended discussions using open source tools. ;-)
The text was updated successfully, but these errors were encountered: