Next steps
Closed this issue · 10 comments
Hi Bastian!
I am thinking about what else can be done with this package, proposed roadmap so far:
-
[merged] add the possibility to delete and modify an annotation from the summary window;
-
[merged] place the annotation on a new line if too long;
-
update software version to 0.5.0 ;
-
update the README (WIP, see: #55)
-
how?
- extract NEWS and Changelog from README into separate files;
- update screenshots;
- add installation instructions;
- document new features
Bye!
C.
Hi!
Here's another feature I always wanted to implement, but never got around to:
- Make the positioning of annotations customizable (right margin vs. next line). Putting annotations on the next line would afford a lot more room, and would work better with narrow windows.
Otherwise, we should finish up all pending changes, then let it sit for a week or two to find lingering bugs, and then push the update to users.
As for the README, we should definitely expand it with all the new features! And check if we accidentally broke any old ones, or want to deprecate any old ones. The annotated diff, for example, turned out far less useful than I thought. Installation instructions would be helpful, too. And pushing people to use melpa-stable instead of melpa, like reasonable people.
Do you have a strong opinion on inline changelogs, versus changelogs in their own file? I don't really have a preference.
The screenshots are another interesting question. They should all use the same color scheme, of course. What kind of color scheme are you using? Regardless, I like to use macOS for screen shots, because of the nice drop shadows you get behind the windows--even though I otherwise rarely use Macs at all.
And once all that is settled we can update to... it seems the next version would be 0.5.0?
Unfortunately i know nothing about packaging policy for emacs. :(
No problem, I'll do that, then, once you're done.
I feel the part regarding the version on the bottom of the README
could be placed in another file (maybe NEWS or something like that. My
opinion is that changelog is more for developers, and news for users;
the information on the README seems more user oriented).So said, this is just my opinion; i have no problem with the current
organization of the README, i leave this decision to you. I am OK with
any decision you are going to take.
I like the partition into developer-focused CHANGELOG and user-focused NEWS. I've never thought of that before.
I am OK for mac screenshot, i like the shadow too! :D
Do you have access to a Mac for taking those screen shots? Otherwise, I can do them at work.
Hi Bastian!
Sorry i think i am not able to answer to your comments on the PR today, thank you they are useful and as usual! :) I think i will write about that tomorrow.
In the meanwhile i have updated the PR #53 and started to works on the feature about placing annotation on their own line instead of right margin:
https://github.com/cage2/annotate.el/tree/annotations-on-their-own-line
I think is a starting point, not a good starting point but a staring point for sure. :)
I have changed the original message in this thread reflecting the little discussion we had, but i could had made mistakes, feel free to point out such errors and i will correct the message.
Bye!
C.
Sorry i think i am not able to answer to your comments on the PR today
Just to make sure... I want you to know that I do not, ever, expect a fast reply at all. I know Open Source work can become a chore, I've been there myself. Open Source should always be fun! That's why we're doing it!
I tend to respond on Github first thing in the morning, because that's what works for me, and it leaves the rest of the day for actual work. But you can totally take your time. Take days, weeks, months, if you want to. There is no rush, at all. In fact, I found it incredibly important to realize that being a maintainer of an Open Source software package is not a job. It does not mean you have to respond quickly, or at all. You do not have a boss. It is a thing you do for fun, nothing more and nothing less.
It is the beauty of Open Source that people can in fact fix their own problems. As maintainers, we give them our work for free. And in return, I think it is only fair that they can figure out problems on their own. We can provide them with guidance, if we feel like it, but there is no obligation to fix other people's problems. That way leads to madness, and burnout.
Which is why I now tend to answer issues and pull requests with passing the ball back to the issuer: Ask them to provide context, or an initial analysis. Not because I need those to fix an issue, but for finding out whether they actually care. There's no point in implementing a feature nobody actually wants to use. The best features are the ones you build because you'll use them yourself. And if nobody cares, I let open issues linger, with a request for help. Sometimes years later someone like you shows up with a vested interest in the project and takes it further. Sometimes the project was just not as useful as initially thought. Either way is perfectly fine.
As a side note to this side note, the corollary to this is that code complexity has to be near the very top of our priority list. I have worked on a project where we let code complexity slide, which lead to subtle bugs, or hard to explain edge cases... in short, it lead to maintenance effort. And as maintainers, we must strive to keep maintenance minimal if we want to keep our sanity, and leave time to work on new stuff.
There's a dangerous slippery slope in Open Source, where a successful project can become suddenly popular, at which points all kinds of bugs are suddenly discovered. And then, strangely, people can become extremely irate and rude and demand those bugs to be fixed. In a software they did not pay for, and could in fact fix themselves. It's all fun and games until that happens, and then it's suddenly real, and ugly. So we need to remain vigilant of code complexity and maintainability. (Although I do feel that the Emacs community, as a whole, is far more forgiving in these matters than other communities).
Umm, anyway, so, take your time!
Hi Bastian!
Are you OK if i would change format from markdown to org for README and NEWS files?
Nothing i can not deal with but i feel org-mode much more comfortable for me, just that.
Bye!
C.
Absolutely! But beware that Github does not render ORG entirely correctly, so you'll have to use a somewhat restricted subset of org-mode's feature set.