• FuelPHP project has very cool feature: Roadmap. Right after 1.1 was released we know what is going on, what are next steps. Some of them will be in 1.2, other in 2.0. But the main point is: information. Community knows what is going on.

    Maybe I missed that, but I cant find similar page for Kohana. Only option is to look at issues, control witch of them are developed, witch are suspended, done or bumped for later releases. Similar roadmap would be very nice way to show community what is going on with kohana, in what direction it is going and what can we expect in 3.3, 3.4 or maybe even 4.0 if there are plans for such major changes.

    Are there any good reasons (beside: it's all in issues) for you, dear devs, to not to create such roadmap?

  • http://dev.kohanaframework.org/projects/kohana3/roadmap

    Fuel's version is basically just styled version from my POV.

  • Might not look as fancy as theirs but it's the same thing.

  • There's also this; Dev-Meeting-2011-07-31 which changes the roadmap and release schedule somewhat.

  • I like Redmine better. It's confusing at first if you're not familiar with bug tracking systems, but if you really want to know the roadmap, it's there...

  • in redmine I have to look at 80 issues, read all of them to see if they are important or not (class separation, complete rewrite, move sth in/out of the core, big functionality changes...), read comments since some of the contain information about additional changes in another libraries... You tell me that it's better than 1 (ONE) page, containing main items with description and progress?

  • That FuelPHP page is pretty useless, since it doesn't actually link to any meaningful information or discussions. But there's a case for Kohana devs to have a digest of the redmine issues, a simple 'what we're working on' blog would be enough, IMHO. But as ever, this is asking for more dev time. :)

  • Over at FuelPHP the Roadmap page is mostly for end-users.

    Here the Redmine page is for developers, who are actively contributing to the project and it makes more sense to see all the information / issues, which one is assigned to whom, etc.

    If you're having trouble with a KO feature, or have any other questions you can always ask here on the forums.

  • It's not about trouble. It's about time, reading 80 issues to get what is going on with next release... I prefer one page solution - quick and simple. However, I get it, this is not Kohana way of communicating with the world. Everything is in the issues, everything is in the sources, everything is buried under the ground, everyone has to dig for himself - putting simple roadmap info would be too easy, Kohana user must be more 'pro' ;)

  • There's really not much value in the "sensational" changes. Often time the minor fixes can be a lot more interesting, and relevant to you; ie. X security hole was patched. In the end it's all just Kohana having a LOT more issues "under discussion" and being more open then fuel--since an alternative way of looking at fuel's short list is "NO to every other issue/suggestion/etc that's not on this list".

  • It's not about open/closed, Fuel or anything like that. It's about information: I just want to know what major changes will be in next release. Right now it's 80 issues to read - all I'm asking is simple page: hey, in 3.3 we will do this, this and that - stay tune, we will update this page from time to time.

    Let's take "Fully Support PSR-0 autoloading requirements" - my reaction was: ok, whatever. But after reading detailed description I realized that this will cover "php 5.3 only" (witch was told long time ago but it's hard to find if you don't read forums or dig into issues), namespaces?, lowercase only file names? And it's buried somewhere in issues, even between comments. I can find this, but I don't want to look at those issues/comments to get brief info about upcoming version.

    A simple page where anyone can see what is going on with next release - guys, is that really to much for you?

  • You can always keep an eye on the migration page of the new guide as it's updated:

    https://github.com/kohana/core/blob/3.3/develop/guide/kohana/upgrading.md

    That will (eventually) have all the important information that you'll need in one place. And just cut the developers some slack, whydontcha? It's not as if you or anyone else here is paying them for their time, now, is it?

  • A simple page where anyone can see what is going on with next release - guys, is that really to much for you?

    You already have this! Your problem is just simply "OMG it's too long" so you want an incomplete version for convenience sake. Completely unnecessary. If you want to follow the development, then you follow everything; or use the filter options. This is too much a niche "wannabe developer" kind of feature; and so not worth the time maintaining.

  • zeebee - this is more or less what I was looking for. Too bad this is not linked anywhere, no sticky topic on the forums 'Upcoming release' with link to that page. For the future releases, I will remember to look at dev userguide. But I still think that this should be sticky topic: at the beginning as a simple info (we planning to do: x, y, z in next release) and at the end there should be a link to userguide.

    Akki - yep, readable info about next release is 'wannabe developer' kind of thing... Sure. Real developers would never have a problem with reading 80 issues with comments and prefer that, instead of simple page "what's new". I guess real developers are not using documentation, since it's all in the sources, right? Can you enlight me what else is crucial to enter "Akki's way of real development"? ;) Akki, get serious, 80 pages to read is better than one page with brief info? When new big version of well known framework is about to be released, Symfony, Zend, Cake, whatever, you go through xxx issues (far more than 80) instead of reading quick info about most important changes? Really? REALLY?

  • @thejw23 just use filters. If you need 1 page magically tailored to you by other people then no offense but obviously you don't know what you're even looking for, IMO. And it's not all rainbow and unicorns either, here's an example magical single page. Is that few enough? =P

    If anything pages like this just encourage misinformation since the idea that you can just look at it for all the changes is just simply flawed, yet that's why you're suggesting it exist for. Kohana then has to deal with "well why wasn't XXX very important change in the roadmap".

    Akki, get serious, 80 pages to read is better than one page with brief info?

    I only see 9. And I could filter it down even more if I was looking for something specific.

  • Let's take "Fully Support PSR-0 autoloading requirements" - my reaction was: ok, whatever. But after reading detailed description I realized that this will cover "php 5.3 only" (witch was told long time ago but it's hard to find if you don't read forums or dig into issues), namespaces?, lowercase only file names?

    Almost forgot about this. Just so there's no confusion, PSR-0 spec is actually completely backwards. The class file has to be in exact case as the class name, not lowercase. Directory structure as well.

  • Akki, you just don't get it. I know how to use redmine, I know how to use filters. And if you want to know what I'm talking about just read my messages in this thread. Again. With understanding.

    Right now I just wonder, if creating one page with roadmap is so bad, will have to be maintained, and it's waste of time, than how about usergiude ? Unofficial wiki is far better. Code is well documented. Api browser is great. Why userguide is still maintained, since it's not needed ? Unofficial wiki plus API browser are far better than userguide. It would be better if unofficial wiki become official and userguide module could be removed, time saved, devs redistributed to other tasks.

  • Right now I just wonder, if creating one page with roadmap is so bad, will have to be maintained, and it's waste of time

    It's a waste of time because it's already automatically generated. We disagree, pretty simple.

    Unofficial wiki plus API browser are far better than user guide

    You mean this thing (http://kerkness.ca/kowiki/doku.php) which isn't relevant at all (and hasn't been for two years)? How about instead of "contributing" to an "unofficial wiki", you contribute to the official documentation!?!?!

    We still need to write docs. We can't rely on users to do it. We have no obligation to duplicate content with a "roadmap" though.

  • @thejw23

    It would be better if unofficial wiki become official and userguide module could be removed, time saved, devs redistributed to other tasks.

    You don't understand what the userguide module does. It's not the docs, it part of the framework's functionality, you can have your own guide/ in your app. What you're actually asking is for Kohana to drop their website. :) Not happening.

    Akki, you just don't get it.

    Unfortunately I do. I just disagree with your perspective since from my POV it's purely a marketing/evangelizing hook that's completely useless for real world problems. And your reasoning on how it's convenient to look at completely ignores how useless looking at it is (what do you do after looking at it?), and how much work is required to maintain it.

  • That roadmap is also quite a turn-off, IMHO. I mean, doesn't seem especially ambitious for a v2.0, makes it look like they've hit a wall in development and this is all they've got, so much Planned and Proposed but little Started ... whereas the redmine roadmap really shows the agile development of Kohana at work.

  • +1 @thejw23

    Dear devs. This discussion shows that there is no sense to propose anything. Roadmap where we have five versions, where some issues were moved from the version 3.0 to unscheduled (over 3.1, 3.2, 3.3, 3.4), is probably a joke. I know, I'm critical, but do not ignore simple questions. Seriously, @thejw23 asked a simple question and you want to prove that he does not understand something.

  • Roadmap where we have five versions

    We actually only have 3 versions.

    where some issues were moved from the version 3.0 to unscheduled

    Impossible, we haven't had anything scheduled for 3.0 in years.

    Seriously, @thejw23 asked a simple question and you want to prove that he does not understand something.

    Not at all, we just want to show that the information is already available, actually in a more useful way (in our opinion) than what he exampled (from fuel). Obviously people have differing opinions on what is useful to them, and we can't satisfy everyone by what we do. We also cannot implement every suggestion that is thrown our way.

  • I think that way of Fuel, Zend (or whatever other framework with a simple roadmap I will mention) is better - it makes clear statement for people who are not interested in digging into redmine issues just to find out what will happen after next release.

    I also think it's all said and done - Zombor get it, I get what Zombor is telling me (we don't have to share same opinion), Akki still don't get it.

    Thanks for all explanations.

  • @thejw23

    The roadmap is not for those people. Yes, I definitely don't get it. What are "those people" doing with the information? What exactly is the difference between an issue that would go on your "fancy roadmap" and one that wouldn't?

    @Riu

    If your users asked for a pretty statistics page that they have no use case for because they are not (practically) using it and know not of anyone who would be using it (over the alternatives), would you waste your time implementing and maintaining it "just because it's pretty" and "they saw it somewhere else and it looked cool" oblivious of the circumstances around it and it's purpose in the context?

    Roadmap where we have five versions, where some issues were moved from the version 3.0 to unscheduled (over 3.1, 3.2, 3.3, 3.4), is probably a joke.

    According to the Kohana process, it's 3 versions because Kohana maintains support for up to 3 versions at a time. A roadmap that wouldn't include the version people are actually still using, and hence would be interested in since it potentially refers to issues they may have, would be the real joke IMO.

    Dear devs. This discussion shows that there is no sense to propose anything.

    You mistake "propose" for "request". If it's a proposal zombor already answered it. If it's a request, it's very superficial and should be done though the normal channels with a proper explanation attached on how exactly that's useful (not "cool", "pretty" etc). Not though the forum, irc, etc. If you're not personally in-the-know on why such a "request" is necessary because it doesn't affect you then find someone who is and have him explain it proper.

  • Kohana maintains support for up to 3 versions at a time

    We actually only "support" two versions at a time, but we work on 3. I don't know how many other frameworks have this support model.

  • I consider the current development branch as just another version; since it's not like it's not usable. But yeah my wording there was off. :)

  • To be fair, sometimes the titles of Redmine tickets (esp those originally contributed by users) aren't always entirely clear about the implications of the fix/feature and so going back and forward between the ticket list and the full descriptions can be a bit involved to get a full sense of what's happening - particularly if you've not been on for a while. And the issue list (even with filters) is not designed to be, and therefore isn't, the best "at-a-glance" presentation of the roadmap for dipping in and out of. The dedicated Roadmap views at http://dev.kohanaframework.org/projects/kohana3/roadmap are better, but again are far from perfect in UI terms.

    Equally, I don't think there's any reason for the devs to spend time maintaining a separate list, particularly as to be useful it would still need to be linked across to the individual issues so that you could easily get the full details and comment on changes you were interested in. It would either take a lot of time to keep up to date, or would be out of date and useless.

    In an ideal world, the Roadmap view on Redmine would be redesigned to make the high level summary of all issues more immediately visually accessible - grouped appropriately by version, type, priority and probably including the start of the ticket description. Metrics like number of comments, number of lines of code in related commits and so on could be used to infer how significant they were. Wontfix, invalid and duplicate tickets could be excluded from the list altogether. There could be an option to subscribe have the roadmap view sent daily or weekly (with changes highlighted) by email. In other words, a ground-up redesign of a live Roadmap view, targeted to framework users rather than core developers.

    All that could be fairly easily done with the Redmine API, by developing a Redmine plugin or by getting involved with Redmine core development. Again, that shouldn't be a priority for the core Kohana team - the system as it is works for them and most of the rest of us.

    If there are people out there who really feel want this feature and believe it would benefit the project, there's nothing stopping them volunteering their time and skills to make it happen.

    In the meantime, I think the single biggest thing we could all do to aid people trying to keep up with Kohana's progress is to make sure that ticket titles are properly descriptive. Titles like "Character support issue", "Please fix docblock", "include_paths" don't really convey much useful information in the issue list. The first is in fact specifically about replacing ellipsis characters in the source with ... for IDE compatibility, and is a fairly minor change, but the title could equally have related to a BC breaking rewrite to i18n, HTML::chars, Database::escape - who knows?

    On that note, I also occasionally look at the list of GH pull requests and there are an awful lot titled 3.3/develop etc rather than with a suitable issue title. Fairly sure that can't be that helpful to the core team, and certainly again makes it harder for users to quickly see what's been happening.

  • In an ideal world, the Roadmap view on Redmine would be redesigned to make the high level summary of all issues more immediately visually accessible

    I agree, the redmine "roadmap" view isn't very useful. It includes issues that were closed as "wontfix".

    On that note, I also occasionally look at the list of GH pull requests and there are an awful lot titled 3.3/develop etc rather than with a suitable issue title. Fairly sure that can't be that helpful to the core team, and certainly again makes it harder for users to quickly see what's been happening.

    We (I , at least) pretty much ignore all pull requests. They only get action if there's a redmine ticket for it. I think jenkins runs builds on PRs and informs the submitter if there's no issue. I could be wrong there though.

  • Re pulls, I knew that but it still wouldn't hurt for them to have a descriptive title - helps the rest of us to see it in our activity stream when the request is created/updated/merged (although now that I'm watching Twitter Bootstrap I barely see anything else on the page!).

    I know there was talk about the build bot flagging pulls without issues but I wasn't sure if it was actually doing it. I used to do a bit of that manually when I happened across new pulls without tickets but haven't had as much time lately and as I say with bootstrap flooding my notifications I don't see new pulls as often as I did anyway.

  • Looking at https://github.com/kohana/core/pull/220 it doesn't seem like the build bot is checking for an issue link.

    Might be easy and worthwhile to add something like "This pull request will likely be ignored unless you have linked it to an issue on http://dev.kohanaframework.org" to the "Build Successful" and "Build Failed" message text just to make sure new contributors are aware of the policy? Though of course they should also have read the contributors docs!

  • +1 to enforcing better titles :)

  • @Akki And how would you 'enforce' that?

    The one thing I can think of is that the devs would rewrite it before accepting the issue...

  • It's not about enforcement, its about all of us taking responsibility as a community for helping each other. We're all developers here, so its surely not that we don't know how to write a proper ticket title - just that people aren't bothering (in my opinion)...

  • Enforcing was the wrong word there. Just editing titles when their wrong is fine really... which is what andrew was suggesting, I think.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion