How to contribute
Akendo opened this issue · comments
Hi mate,
thank you very much for the work you're doing! I've used the older app version and started to get frustrated with. This version seems to be a bit smoother. I'm not an android develop(Everything that is Android feels a big yacys...), however, I wish to help you here if possible. There are several wishes I've seen so far:
- Missing project overview
- Slow responses
- Overhead in the task completion.
- Better handling for the tag filtering
So far,
akendo
Also, the task creation, while simple, lacks the ability to set tags, project or anything else. I first have to remove any filter and sort the task by 'entry'. This adds more effort for someone to create any tasks.
Another great feature would be to run custom task commands.
Also, it would be great to have the option to create shortcuts to specify filtering and/or project views.
Sorry for my level of noise, thinking out load here, if you don't mind ;-)
Looks good, this is really the first list of features-requests/issues by a user, I really appreciate it. I'll try to reply soon, with possibly some combination of requests for clarification, what features I have been considering that might provide workarounds sooner, where I have had difficulty with planning some of the above, and how we might expand on some of these.
Some of these potentially are ready to have their own dedicated issue thread. And/or this project potentially could use a text chat outside of issue threads? Not sure if anyone is interested, or has a preference, for something like Github Discussions, Gitter, IRC, etc.
I also wanted to say, describing issues and feature requests is an excellent way to contribute, not sure if you find this a sufficient trajectory for the issue as you titled it.
Looks good, this is really the first list of features-requests/issues by a user, I really appreciate it.
You're welcome, I'm as pleased as you're.
I'll try to reply soon, with possibly some combination of requests for clarification, what features I have been considering that might provide workarounds sooner, where I have had difficulty with planning some of the above, and how we might expand on some of these.
Sure. I would assume, that a How to contribute document might be necessary. I have some lying around and could use/contribute it to the project. But do not nail me down on that fact ;-)
Some of these potentially are ready to have their own dedicated issue thread. And/or this project potentially could use a text chat outside of issue threads? Not sure if anyone is interested, or has a preference, for something like Github Discussions, Gitter, IRC, etc.
Sure, just give me a hint where exactly, and we can arrange a get together.
I also wanted to say, describing issues and feature requests is an excellent way to contribute, not sure if you find this a sufficient trajectory for the issue as you titled it.
Absolutely, from what was written it was rather a thinking out load. The question is: How much detail are necessary for you?
So far,
akendo
Also, it would be great to have the option to create shortcuts to specify filtering and/or project views.
I opened issue #4, to approximate the idea of shortcuts.
Do you feel more strongly about a specific notion of shortcuts, rather than just multiple persistent views?
If so, I might need help imagining the user experience for this.
Also, the task creation, while simple, lacks the ability to set tags, project or anything else. I first have to remove any filter and sort the task by 'entry'. This adds more effort for someone to create any tasks.
I opened the following issue for this one: #5.
No promise on if/when I will begin work on this, but the issue is there for discussion and tracking.
- Better handling for the tag filtering
Can you clarify what you mean here?
The most annoying thing I've noticed, with tag filters specifically, is how hard it is to visually scan and remove all the filters. Maybe selected tags should be bold, and/or +next would be green, -next would be red. I considered a "clear tag filters", but I've not decided if it's worth it to me, at least not yet. I generally try to keep the UI as simple as possible, looking for solutions to usecases that are either general enough, or annoy me enough, with no sufficient workaround.
It might be nice to indicate the tags that are matched on as bold in the display of the task list item. But I guess that doesn't show what's filtered out. But at least you can see you have some tag filter toggled on. It wouldn't be too hard to code, but a little bit tedious. And it doesn't seem like an "obvious" feature, I'm not sure I like it.
I also plan to implement a frequency count next to each tag filter, indicating how many (pending?) tasks have that same tag, and a toggle to sort the tags either alphabetically (which they are currently), or by frequency. I saw this feature in TaskwarriorC2.
Hmm, or did you mean an issue with persistence of tag filters? I've noticed some of that, it's possible I'll wait to fix this until I'm working on issue #4.
- Missing project overview
Do you mean sorting and filtering the task list view by the project attribute? And showing the project string in each task in the task list view?
- Overhead in the task completion.
Do you mean too many clicks to set a task's status to completed?
I've sort of thought a batch editing feature would be nice, but I haven't thought it all the way out. User could select multiple tasks, then sort of apply a batch edit, for example, marking them all as completed. I was imagining I might generalize the task detail editing page to handle both batch edits and single task edits in some elegant way.
Potentially, such a feature, though maybe difficult to implement, might make it slightly less annoying to have so many clicks to mark a task completed.
However, I'm not sure batch editing is an itch I find motivating enough to scratch, at least in the foreseeable future.
- Slow responses
Can you clarify which responses you are referring to?
Another great feature would be to run custom task commands.
Can you give examples of which commands you are referring to?
I'm not an android develop(Everything that is Android feels a big yacys...), however, I wish to help you here if possible. There are several wishes I've seen so far: ...
I also wanted to say, describing issues and feature requests is an excellent way to contribute, not sure if you find this a sufficient trajectory for the issue as you titled it.
I would assume, that a How to contribute document might be necessary.
I'm not sure yet what contributing means. Do you mean you want guidelines on submitting PRs? If so, I'm not sure I'm prepared yet to review and merge PRs. Or please clarify if I've not addressed something in the thread. Are there other aspects of contributing that I should document?
Feel free to clarify further, but this seems to be about pull requests, and some apparent need to document it in the negative, caused by this issue: dear-github/dear-github#84.
I don't think this is a priority for me, in the near future, so I'm closing out the issue, treating it as a request for clarification on the pull request process, which is not currently being planned.
This is a someday/maybe/no-promises. Maybe it gets done sooner if it occurs to me how to add it to docs while I'm rewriting README for another reason.
Again, feel free to continue discussion in this thread if you prefer, on the tangential issues, as well as if you want to clarify "how to contribute" within the thread, but not necessarily to be documented in the repo anytime soon. That is, I'm happy to discuss it, in this thread or elsewhere, but I don't want to prioritize documenting it, that is, adding commits to the repo for it.
I hope I did not miss the point by too much, apologies if I did.
Hi @bradyt thank you very much for that much effort!
I tried to answer top to bottom approach: What do I mean with contribution? Everything that help to improve/change/alter or modify the project. In general, users wish to add feedback to the project should be considered to be a contribution. Usually in a software project we tend to understand this as code only. However, main users have ideas that might be worth talking about and that the core of the question: How should this be done?
An example of this are bug reports. How much information do you need to handle a bug requests. Putting these needs into a template can save much time.
Here is another example: What would be qualified as a feature requests? By the amount of work you've done so far that you took my requests series. But what format could it have been written to reduce overhead or source of misunderstanding?
Also, a list of things that might be helpful or currently necessary: For instance: Translation. To have a simpler reference, I like to share the contribution page from the Task Warrior Project[0]. They have an entry section dedicated for contribution[1].
To the negative case: Sure that's validate as well. I'm not here to define how you should do your work. It is a difficult task to work collaboratively, in particular when writing code. You should expect people to open PR without reading any of your documents. It is rather to define what is your responses. In the end it is often a decision problem.
The simple solution is the README document or a separated one like CONTRIB or such.
My purpose for you: I'm looking my stuff up and check if I can contribute this to the project and create a PR with the necessary files. Otherwise, I have to rewrite it from hand and would send it in some time later in the next week. This would consist of four different post types bug, feature requests, support requests and miscellaneous.
We can discuss this then in the PR. Otherwise, I might have one or two bugs report that I have seen so far. However, I'm not sure what you need. Because I do not wish to share my task data, and it might be difficultly without to reproduce.
[0] https://taskwarrior.org/docs/contribute.html
[1] https://taskwarrior.org/docs/#contrib
Apologies that writing up guidelines for filing issues is not a higher priority.
I appreciate you illustrating various scenarios motivating issue templates.
I do hope to hear more about those issues soon.
Better handling for the tag filteringCan you clarify what you mean here?
Sure: I have 148 active tags in use. When I open up the tags list all of them are shown. I have to scroll down to find the one I'm using most of the time right now. Not the exact behavior I seek.
The most annoying thing I've noticed, with tag filters specifically, is how hard it is to visually scan and remove all the filters. Maybe selected tags should be bold, and/or +next would be green, -next would be red. I considered a "clear tag filters", but I've not decided if it's worth it to me, at least not yet. I generally try to keep the UI as simple as possible, looking for solutions to usecases that are either general enough, or annoy me enough, with no sufficient workaround.
Instead, a list of preferred filter should be shown. Like; Oh you have used this filter in the past. In there you can add one or many tags out of to the list of existing tags. At least this would feel more intuitive to me, because many tags are there for a reason to be used later in time, while others are things I used to figure out what I'm doing right now +habit for instance.
It might be nice to indicate the tags that are matched on as bold in the display of the task list item. But I guess that doesn't show what's filtered out. But at least you can see you have some tag filter toggled on. It wouldn't be too hard to code, but a little bit tedious. And it doesn't seem like an "obvious" feature, I'm not sure I like it.
Maybe you sort the used tags to the top? This way you see it right away. But, I agree, these visual things are not that critical.
I also plan to implement a frequency count next to each tag filter, indicating how many (pending?) tasks have that same tag, and a toggle to sort the tags either alphabetically (which they are currently), or by frequency. I saw this feature in TaskwarriorC2.
Sounds great.
I hope you can understand what I'm trying to express here.
best regards,
akendo
Apologies that writing up guidelines for filing issues is not a higher priority.
I appreciate you illustrating various scenarios motivating issue templates.
I do hope to hear more about those issues soon.
That's perfectly fine.
I am looking forward to reviewing your message on task filters.
A quick note on another matter. It occurs to me that, while I don't think I have enough finalized notes on contributing to want to edit the repo, I do have enough of sketched ideas, to add them as a draft on the wiki. Later I will probably add a CONTRIBUTING.md that points to the page.
Better handling for the tag filtering
Can you clarify what you mean here?
Sure: I have 148 active tags in use. When I open up the tags list all of them are shown. I have to scroll down to find the one I'm using most of the time right now. Not the exact behavior I seek.
Instead, a list of preferred filter should be shown. Like; Oh you have used this filter in the past.
Ah, I think you're bringing to my attention, that the tag filter UX does not scale well in number of tags. Very good point.
By "preferred filter... you have used this filter in the past", what sort of UI are you imagining? What sort of logic is used, where does the new information come from?
It seems plausible that issue #4 could reduce the annoyance when selecting tag filters from a long list. That annoyance might also be reduced if the idea of sorting tag filters by tag frequency is implemented. Filtering tags by partial string match might also be considered a way to deal with issues of scale. The Foreground project (I added links to related apps at the wiki) recently added a filter UI, and each filter value is typed in as a string, if I recall correctly.
I wonder if sorting tags filters by the most recent associated modified date would better approximate what you mean by "preferred filter". I'm not aware of prior art with this feature.
[...] many tags are there for a reason to be used later in time, while others are things I used to figure out what I'm doing right now +habit for instance.
I'm not sure I understand sufficiently. Would sorting tag filters by modified date be a close fit to improve this? Or maybe you can describe a UI and implementation that fits closer to the issue? I would be curious if it is as easy to implement and maintain, though I'm not claiming I think sorting tag filters by modified, currently ranks high in my priorities, considering maintenance and generality of solution.
Maybe selected tags should be bold, and/or +next would be green
Maybe you sort the used tags to the top? This way you see it right away.
Maybe I should duplicate the used tags to the top, but also keep them visible in the available list. Rather than just having the tags jump position, which increases UI glitchiness with the list rewrapping itself.
Not sure I want to go in that direction.
If you noticed a task's tag editing UI does have this jumping glitchiness, I considered the saved order of tags significant enough to display to user.
I am looking forward to reviewing your message on task filters.
A quick note on another matter. It occurs to me that, while I don't think I have enough finalized notes on contributing to want to edit the repo, I do have enough of sketched ideas, to add them as a draft on the wiki. Later I will probably add a CONTRIBUTING.md that points to the page.
* https://github.com/bradyt/taskw-dart/wiki/Draft-of-CONTRIBUTING.md
Seems good to me! It is more than I anticipated.
Ah, I think you're bringing to my attention, that the tag filter UX does not scale well in number of tags. Very good point.
By "preferred filter... you have used this filter in the past", what sort of UI are you imagining? What sort of logic is used, where does the new information come from?
TBH: I do not know, however, having some type of picker that allows you to select a given tag might be an idea. I could try to create wireframe to make something up.
It seems plausible that issue #4 could reduce the annoyance when selecting tag filters from a long list. That annoyance might also be reduced if the idea of sorting tag filters by tag frequency is implemented. Filtering tags by partial string match might also be considered a way to deal with issues of scale. The Foreground project (I added links to related apps at the wiki) recently added a filter UI, and each filter value is typed in as a string, if I recall correctly.
Possibly, the filter would be great. I think the general problem is sampling the underlying amount of tags at the moment without much effort. For instance, all tags are sorted by the alphabet, but it will be distinguished between upper and low case.
Making it quite some effort to scroll through the list to a given tag and after noticing that the desired tag does not exist in the list you have to scroll again further to get to the lower/upper case tags.
I wonder if sorting tags filters by the most recent associated
modifieddate would better approximate what you mean by "preferred filter". I'm not aware of prior art with this feature.
My idea here is the following:
You keep track of each tag the user has selected. Whenever a tag is selected it would increase the counter. Think of this like the Google suggestion function. It is a form of autocomplete, allowing the user to get a tag based on frequent usage.
Not sure how much effort such type of feature would be.
Recent tags
I think adding a feature to store persistent history of selected buttons would be lower priority than the other incremental improvements I described above. For example, #4 provides good generality, and sorting tag filter buttons by modified I think approximates your recent history proposal, and manages to accomplish this with only a "pure" function of the existing Taskwarrior data.
Alphabetic sorting
The sorting of tags as A, B, C, a, b, c, instead of A, a, B, b, C, c, does seem a little quirky, but I think it is low priority to discuss, because this is roughly the behavior of CLI Taskwarrior, and I think the annoyance will be reduced if #4 is implemented. If you'd like an issue opened for tracking, feel free, but I'm not sure when I will make time to think about it more.
I rarely use capitalization in tags. Presumably this arises when tagging tasks with proper names, for example delegating, or maybe tasks to do at a landmark location. I realize capitalization has both pros and cons, for example readability versus ease of typing.