Wedge

iface ?

I don't know which is sadder: you wasting valuable time on this or me wasting valuable time thinking of such rubbish suggestions :)

I'd rather waste 2 days waiting on the 'right' combination of folder names, than not renaming them, and ending up screaming at my screen every time I want to do a commit.

Unfortunately, as I just posted on the 'One theme' topic, even renaming folders wasn't enough of a safe strat. I'm a bit lost now.

(That, plus the fact that even after moving files around, I still have some fixing to be done. Even, a lot.)

Oh, scratch that... Looks like making a fake commit fixed my problem.

Cool!

Sure! Now I need to:
- determine whether I keep the $sourcedir variable or upgrade it to an APP_DIR constant.
- fix all other branches (see rebasing topic).
- make a fake install, and fix the process.
- do a quick overview of Wedge, try to determine what will surprise/disappoint users, and try to fix that. :P
- make a quick list of all areas in Wedge that are NOT finished yet but will be finished in the coming weeks, such as notifications, privacy, contact lists, etc. (Is that all? :P)
- determine whether I use github.com/Wedge/wedge or githubhom.com/wedge/forum as the main repo (what? wedge/forum is better, but then it means Wedge forks will show up as 'myaccount/forum', with no mention of Wedge whatsoever...)
- determine whether I use github.com/Wedge or github.com/Wedge (the latter looking better in hardlinks, but not in the actual github page where you have to cope with a lowercased title... It may be stylistic, but...)
- write a blog post.
- push the actual thingy.
- pray that it doesn't underwhelm, after 3 years of work.

Estimated date: January 20.
Personal goal: January 16.

Set a date to complete functions, than add two weeks for testing and debug. Push day after the two week mark for better or worse. Don,t forget to remind everyone it is the first beta of many to come.

You will NEVER make it 100% perfect. Any software that is perfect and does not have bugs is obsolete. The sooner you release a beta, the sooner you will find out about bugs when running on other configurations. You will also find out what us users like, dislike and want added.




Grumpy old man


John

Or it's deceptively simple. If you only have 10 lines of code and it does its job, your software might be both perfect and never obsolete. You never know.
Believe me, I know how handling a project works. My first project release was 23 years ago. And all I know is that if it's way past its expiration date (mostly thanks to Pete), it's pretty much impossible to get the 'momentum' back, so you have to accept that it'll never be successful beyond a tiny, very minor niche audience. I've had my share of professional successes and failures, so I can deal with either of these fairly well enough. Not a big deal. But it sure is better when it's a success, of course.
The only thing that worries me is that niche audience = requires financial involvement from users to make it a viable long-term solution, = less likely to acquire new 'customers' (and I don't like seeing my users as customers, so it's bad to begin with), = more likely to go out of funds.
But it's not really time to consider this. Right now, I'd like to focus on the positive things, i.e. the Wedge repo will soon be public, which I'm the only one to hate, so... Everyone rejoice, eh..?

I just finished moving my branches out of the way, they're now (for the most part) moved to the stash repo, so I can now reduce the repo's size, probably by cloning it, and I'm all set for a last check.Release early, release often.
This would have been possible if Wedge was a public repo from day one. Which wasn't possible, because of the SMF 2 beta license at the time we started the project, so... No need to look behind.

Nao = a perfectionist. I mostly give developers their and breathing space to release their software at their convenient time, alongside motivation, it is the highest payment that can ever be made to them.