Posting in these forums is disabled. These forums will be available for archive purposes. Please join the new forums at the links below:
|Page 1 of 1||[ 5 posts ]|
Hi all, I'm starting this thread to solicit ideas for ways to increase our PR (Preview Release) adoption during the release process. We find that the more folks who try out PRs ahead of time, the greater the chances of finding edge case bugs that might force a quick point release.
So, if you have ideas about how we can get PRs out to folks as well as quickly getting feedback, please post to this thread.
How about an a dedicated bug reporting page? The goal would be a quick overview of reported bugs, a streamlined interface for reporting issues, and other things like release notes or breaking changes. Even a saved ticket report would be good, but I'm thinking of something more streamlined, and as more of a portal page for the PR.
At the moment, I can't find 3.10.0pr1 in the bug system at all (I must admit I haven't searched for a PR SOP, and it it looks like PRs are not lodged as versions in the bug system since 3.0.0, so maybe I should be looking at the dev master? Still...)
It should be rather easy, because now it is extremely difficult to find PRs.
Under Download, there should be a section for non stable releases. This is pretty standard everywhere. That is the first place I look when I want to find a release, and get disappointed each time on YUI. I don't remember how I did last time, probably I followed a link in one of the mails I receive.
Doing it this way (subsection under "Download") you will have downloads and corresponding trials also from people who is not signed up to mailing lists.
Trying to find an unstable release this time from the website, it took me ages to find it under "blog" and it is again as a link on a post. That is the last place I would look after.
What if I wanted to compare 2 different unstable releases?
I guess you say: "use git and pull it from github", but it is not the same thing to have it wired up in a git cycle, or just download the package and test it more or less statically. It is just one more barrier to overcome, and for each barrier you loose both testers and users.
Well, I see now that you have the blog nicely categorized and a "releases" category that gives me everything I was looking for. Then you just need to add a link in the download page to that blog category page. That tiny link would do a huge difference.
Also I would change the name of "blog" in the menu into something more precise about the true nature of that blog. Maybe something like "on going development" or "Development right now" or similar.
while I am at looking at the structure of the site:
The menu item contribute>YUI on github is not much telling, you get a huge list of github project and are let alone with searching what and where.
Provided that we want people to be involved in YUI3 development, it would be a big help to:
2. Add an item with "Contribute to YUI3" linking to the wiki page of the yui3 project on github.
Then on that wiki page (yui3 on github) I would definitely move up the title "Get Involved" at the first place (yes, current contributors don't need to see it each time, but it's no cost to them to pass it over, while new users (provided they reached that page), risk very well never to see it.
Furthermore I see from the mailing list that even committers, are not always aware of the details of "Get involved". In this sense this section should be enhanced. See below.
I would also move up "Future", at least above "Current Release".
For "Get Involved" I would change the name of "Contributing" into "How to start" (that title is already listed right under "Get involved").
Then I would change the page "Contributor Model" removing all the links inside "Contribution process" that are linking to pages already linked to from the page Contributing/How to start.
Hence, under that section "Contribution process" I would only keep 1 link to a separate page - called "Contribution process". And that page would only have the links currently contained in this sentence taken from that section: "Contributors should review YUI’s Contribution Standards and get familiar with the project’s Developer Workflow.".
I would also list this new page, "Contribution process" with an individual link inside the page:
https://github.com/yui/yui3/wiki under the link "contributor model".
At the end of this exercise the page:
will have at the top of it a section and links to separate pages as shown below
How to start
Contributor Mailing List
|Page 1 of 1||[ 5 posts ]|
|You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum