Thread: jobs.postgresql.org text.
until we get something better, can someone with proper access put the
following file up on jobs.postgresql.org? (or give me access to do it)
I am going to put this text on techdocs.postgresql.org/jobs/ as well.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Attachment
Robert, > until we get something better, can someone with proper access put the > following file up on jobs.postgresql.org? (or give me access to do it) > I am going to put this text on techdocs.postgresql.org/jobs/ as well. Funny you should mention this. My partner just today accepted my proposal that we develop a web app for jobs.postgresql.org in exchange for publicity for our/his consulting business (i.e. a "Developed by Ascher Consulting" link on the bottom of the screen somewhere). We expect to be able to create something and have it running by the end of January, barring unexpected delays. However, I have some questions for this group: 1) is that kind of publicity for a donor acceptable? 2) How soon will we have stable templates/css pages for www.postgresql.org Ver3? We need these to design the pages. 3) we have a spec for the application. Does anyone want to comment on it? I'll send it va PDF. -- -Josh Berkus Aglio Database Solutions San Francisco
On Tue, 2 Dec 2003, Josh Berkus wrote: > 3) we have a spec for the application. Does anyone want to comment on it? > I'll send it va PDF. Any reason why you could not just put a URL? This way anyone interested in providing feedback can do so. In the mean time I am interested in providing feedback.
Francisco, cc'd to the list so that I don't have to have this discussion twice. > I found the first page a little confusing. > If you send me the text I could re-write it and send you back what I think > may be a bit clearer and perhaps shorter. Maybe after we've resolved the actual issues with the planned functionality. AFAIC, nobody but the www list and maybe core needs to understand this spec. > On the first page I would like to better understand what you mean by > "Applications will be received by the jobs... and forwarded > on to a specified email... to prevent email spiders? I wasn't clear after > that what will be emailed to users? The contact info? In other words: Employers will enter jobs and their contact info. The jobs but *not* the contact info will be made public. Applicants will fill out a form, and the system will e-mail its contents (and any attached resume) to the employer. There are a few reasons for doing things this way rather than simply posting the employer's contact info and letting people contact them on their own. These include: -- Protection for employers from being bombarded with spam every time they post an ad; -- Protection for our job listings from being "mined" by an agency or online job web site; -- Preserving the possibility of eventually turing jobs.postgresql.org into a revenue stream to support postgresql. > -Publicly accessible jobs search screen > You mention a job type there. I was thinking that maybe we may be better > off such option. This can be restrictive and cause some confusion. For > instance prospective employeers may not be sure which category a job > should go under. Or someone may miss out a job because it was > miss-classified. I disagree very strongly. If this site gets as much use as we want it to, we need some kind of categorization to let searchers filter. Pretty much every other job listing service in the world has job categories; I don't see bucking the trend on this one. Certainly we want to stick to a small number of easy-to-understand categories. For example, I was thinking of: Database Administrator (DBA), Software Development, Performance Tuning, PostgreSQL Support, General System Administrator, Training, and Other. > From company to company, local to local, country to country views on a set > of job duties may vary and type may just be a point of confusion. Or may not. Look, from my perspective, I don't want to even see jobs in the "General System Administrator" category; they don't apply to me. Other applicants may *only* be qualified for training. They should be allowed to filter by this, just like applicants will filter by Full-Time, Part-Time, or Consultant to match their availability. > You mention in there "Resume Upload". I don't think this is the right > place to upload a resume. I think people looking for jobs should be able > to upload a resume for their profile. We will not be storing applicant profiles on the system. This would entail about 30 hours of additional work, half of which for security, and we're not going to do it. Also, in the current economy, applicant profile storage would bloat the database and become and administrative headache. > ps. It put a smile on my face the requirement to support 10,000 users per > day. I can only hope for the site getting that busy. I would have a better > chance of working with PostgreSQL for a living if the site ever because > that busy. :-) Actually, I was thinking 10,000 *applicants* per day; if we got as much as 100 employers per day, I'd be ecstatic. I doubt DICE.com gets 10,000 employers per day.... -- Josh Berkus Aglio Database Solutions San Francisco
On Fri, 12 Dec 2003, Josh Berkus wrote: > > On the first page I would like to better understand what you mean by > > "Applications will be received by the jobs... and forwarded > > on to a specified email... to prevent email spiders? I wasn't clear after > > that what will be emailed to users? The contact info? > > In other words: > Employers will enter jobs and their contact info. The jobs but *not* > the contact info will be made public. Applicants will fill out a form, > and the system will e-mail its contents (and any attached resume) to the > employer. > > There are a few reasons for doing things this way rather than simply posting > the employer's contact info and letting people contact them on their own. > These include: > -- Protection for employers from being bombarded with spam every time they > post an ad; > -- Protection for our job listings from being "mined" by an agency or online > job web site; > -- Preserving the possibility of eventually turing jobs.postgresql.org into a > revenue stream to support postgresql. Altho I agree with all three reasons, in this day and age of heavy spam, I think 1 is definitely the big one ... but ... What information is provided about the "employer"? I take it company name and such is still provided? > Certainly we want to stick to a small number of easy-to-understand > categories. For example, I was thinking of: Database Administrator > (DBA), Software Development, Performance Tuning, PostgreSQL Support, > General System Administrator, Training, and Other. Will cross-categories be permitted? Maybe a max of 2 or 3 per job description, but would provide a bit better coverage where some overlap may be appropriate? > > From company to company, local to local, country to country views on a set > > of job duties may vary and type may just be a point of confusion. > > Or may not. Look, from my perspective, I don't want to even see jobs in the > "General System Administrator" category; they don't apply to me. Other > applicants may *only* be qualified for training. They should be allowed to > filter by this, just like applicants will filter by Full-Time, Part-Time, or > Consultant to match their availability. Point: there is nothing that stops an applicant from searching other categories ... if they can't find something under "DBA", but are wondering if something is available under GSA, they can still go check it out ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc, > What information is provided about the "employer"? I take it company name > and such is still provided? > Yes, we were planning on company name. Also, keep in mind that jobs have to be "approved" by the site admins before they go up. -- -Josh Berkus Aglio Database Solutions San Francisco
On Fri, 12 Dec 2003, Josh Berkus wrote: > Marc, > > > What information is provided about the "employer"? I take it company name > > and such is still provided? > > > > Yes, we were planning on company name. > > Also, keep in mind that jobs have to be "approved" by the site admins before > they go up. Granted, the only reason I was wondering is that there are some ppl out there that are "employer conscious", in that some places, no matter how good the money, they just won't work for. So knowing the who before applying tends to be important ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Mon, 15 Dec 2003, Francisco Reyes wrote: > On Fri, 12 Dec 2003, Marc G. Fournier wrote: > > > Point: there is nothing that stops an applicant from searching other > > categories ... if they can't find something under "DBA", but are wondering > > if something is available under GSA, they can still go check it out ... > > > My feeling is that for some time there will be few jobs posted and people > may probably just take a look at all jobs posted. I really hope/wish/dream > of when it will be busier than that., I don't think it will be any > time soon, if ever. I would image that there would be an 'All' category, no? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Mon, 15 Dec 2003, Francisco Reyes wrote: > I think at the very least Employer name and location for the job. Some > companies may have offices in several cities or may be thinking of > opening a new office. re: location ... good point ... again, as the system 'fills up', the ability to just list jobs in specific locations (as well as All) should be available ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Mon, 15 Dec 2003, Marc G. Fournier wrote: > On Mon, 15 Dec 2003, Francisco Reyes wrote: > > > On Fri, 12 Dec 2003, Marc G. Fournier wrote: > > > > > Point: there is nothing that stops an applicant from searching other > > > categories ... if they can't find something under "DBA", but are wondering > > > if something is available under GSA, they can still go check it out ... > > > > > > My feeling is that for some time there will be few jobs posted and people > > may probably just take a look at all jobs posted. I really hope/wish/dream > > of when it will be busier than that., I don't think it will be any > > time soon, if ever. > > I would image that there would be an 'All' category, no? Either that or if all selections are blank.
On Mon, 15 Dec 2003, Marc G. Fournier wrote: > On Mon, 15 Dec 2003, Francisco Reyes wrote: > > > I think at the very least Employer name and location for the job. Some > > companies may have offices in several cities or may be thinking of > > opening a new office. > > re: location ... good point ... again, as the system 'fills up', the > ability to just list jobs in specific locations (as well as All) should be > available ... Which brings up another point. I think most companies will NOT pay for relocation. I think there should be a field "pay for relocation" which should default to no. This for the rare case for companies willing to pay some/all of the relocation expense.
On Fri, 12 Dec 2003, Marc G. Fournier wrote: > On Fri, 12 Dec 2003, Josh Berkus wrote: > > > Yes, we were planning on company name. > > > > Also, keep in mind that jobs have to be "approved" by the site admins before > > they go up. > > Granted, the only reason I was wondering is that there are some ppl out > there that are "employer conscious", in that some places, no matter how > good the money, they just won't work for. So knowing the who before > applying tends to be important ... I think at the very least Employer name and location for the job. Some companies may have offices in several cities or may be thinking of opening a new office.
On Fri, 12 Dec 2003, Marc G. Fournier wrote: > Point: there is nothing that stops an applicant from searching other > categories ... if they can't find something under "DBA", but are wondering > if something is available under GSA, they can still go check it out ... My feeling is that for some time there will be few jobs posted and people may probably just take a look at all jobs posted. I really hope/wish/dream of when it will be busier than that., I don't think it will be any time soon, if ever.
On Fri, 12 Dec 2003, Josh Berkus wrote: > In other words: > Employers will enter jobs and their contact info. The jobs but *not* the > contact info will be made public. > Applicants will fill out a form, and the system will e-mail its contents (and > any attached resume) to the employer. Ok. Understand it better now. Wouldn't it be better to have the resumes on the service and to just have prospective employees be able to have multiple resumes? This way when there is an application they can tell the system which resume to point to for that particular application. Besides convenience for the prospective employee there is an extra advantage. Reduced potential liability. If you EVER send attachments to prospective employers what will happen if someone fakes an email as coming from you and sends a trojan or a virus? Sure you will be able to prove that it didn't come from you, but that is one employer that may shy away from user the service. If you NEVER send attachements then you can even wwarn people that any email coming their way with an attachemtn from your service that the attachment should NOT be looked at. > I disagree very strongly. If this site gets as much use as we want it to, we > need some kind of categorization to let searchers filter. Pretty much every > other job listing service in the world has job categories; I don't see > bucking the trend on this one. Really? I have never seen categories in the sense you are talking about. My experience is with Hotjobs, Monster and a few others. They have categories like IT, programmer, etc.. but these are very general categories and most of the time I have never used them to look for a job. I usually use the 'keywoard' search functionality. > Certainly we want to stick to a small number of easy-to-understand categories. > For example, I was thinking of: > Database Administrator (DBA), Software Development, Performance Tuning, > PostgreSQL Support, General System Administrator, Training, and Other. Not a bad list, but the system should be flexible so the administrators can add. > We will not be storing applicant profiles on the system. This would entail > about 30 hours of additional work, half of which for security, and we're not > going to do it. Also, in the current economy, applicant profile storage > would bloat the database and become and administrative headache. So people are going to attach or cut/paste their resumes? Sounds cumbersome. Just as you said above about doing something primarily because every one else does it, storing the resume would go under the same category. Plain text should not text so much space to store and could possibly even be compressed.
Francisco, > Wouldn't it be better to have the resumes on the service and to just have > prospective employees be able to have multiple resumes? This way when > there is an application they can tell the system which resume to point to > for that particular application. But you've missed two important points I addressed in my earlier e-mails: 1) We (my team) does not want to code that functionality. It would expand the scope of the project by at least 75% and we're just not interested. If you want to add that to what we contribute, you are welcome to do that later. 2) Storing resumes, employee profiles, etc., will have significantly greater storage and security requirements than the storage of job listings, and these issues will have to be addressed. Using our spec, they can be ignored/postponed. >If you EVER send attachments to > prospective employers what will happen if someone fakes an email as coming > from you and sends a trojan or a virus? Mmmm... yeah, we'd better put in a filter to limit the MIME encoding and extensions of resume attachements to DOC, PDF, WPD, TXT & SXW. > I have never seen categories in the sense you are talking about. My > experience is with Hotjobs, Monster and a few others. They have categories > like IT, programmer, etc.. Precisely. And just becuase you don't use them doesn't mean that others do not. > > Database Administrator (DBA), Software Development, Performance Tuning, > > PostgreSQL Support, General System Administrator, Training, and Other. > > Not a bad list, but the system should be flexible so the administrators > can add. Maybe. I can see adding a couple new categories after the system is launched and we get feedback from the users. Otherwise, I think the categories should be rather inflexible; otherwise we risk ending up with 80 categories, 50% of which have only one job in them. > So people are going to attach or cut/paste their resumes? > Sounds cumbersome. Well, if you don't like it, you're welcome to ready your PHP skills. After you draft a spec to deal with the security issues raised by online storage of resumes .... -- -Josh Berkus Aglio Database Solutions San Francisco
People, > re: location ... good point ... again, as the system 'fills up', the > ability to just list jobs in specific locations (as well as All) should be > available ... We are planning a free-text search on "location", most likely. Unfortunately, it's not really practical to have a list of locations for a worldwide application. And of course there will be a "all" search for categories. -- -Josh Berkus Aglio Database Solutions San Francisco
On Tue, Dec 16, 2003 at 09:02:46AM -0800, Josh Berkus wrote: > People, > > > re: location ... good point ... again, as the system 'fills up', > > the ability to just list jobs in specific locations (as well as > > All) should be available ... > > We are planning a free-text search on "location", most likely. > Unfortunately, it's not really practical to have a list of locations > for a worldwide application. I have a framework that can come pretty close w/Javascript and some ISO standard country/subcountry designations. :) > And of course there will be a "all" search for categories. Yay! Cheers, D -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 cell: +1 415 235 3778
On Tue, 16 Dec 2003, David Fetter wrote: > On Tue, Dec 16, 2003 at 09:02:46AM -0800, Josh Berkus wrote: > > People, > > > > > re: location ... good point ... again, as the system 'fills up', > > > the ability to just list jobs in specific locations (as well as > > > All) should be available ... > > > > We are planning a free-text search on "location", most likely. > > Unfortunately, it's not really practical to have a list of locations > > for a worldwide application. > > I have a framework that can come pretty close w/Javascript and some > ISO standard country/subcountry designations. :) If you use the Geo::IP package, when someone hits the site, it could auto-matically display listing for their location too ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Tue, Dec 16, 2003 at 09:02:02PM -0400, Marc G. Fournier wrote: > On Tue, 16 Dec 2003, David Fetter wrote: > > > On Tue, Dec 16, 2003 at 09:02:46AM -0800, Josh Berkus wrote: > > > People, > > > > > > > re: location ... good point ... again, as the system 'fills > > > > up', the ability to just list jobs in specific locations (as > > > > well as All) should be available ... > > > > > > We are planning a free-text search on "location", most likely. > > > Unfortunately, it's not really practical to have a list of > > > locations for a worldwide application. > > > > I have a framework that can come pretty close w/Javascript and > > some ISO standard country/subcountry designations. :) > > If you use the Geo::IP package, when someone hits the site, it could > auto-matically display listing for their location too ... It's the Geo::IP::ICBM module that has me a little worried. ;) Cheers, D(uck and cover) -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 cell: +1 415 235 3778
On Tue, 16 Dec 2003, Josh Berkus wrote: > But you've missed two important points I addressed in my earlier e-mails: > > 1) We (my team) does not want to code that functionality. Ok so do what you can and then others, including myself, could later on decide if they want to pickup the ball and add the extra functionality. > >If you EVER send attachments to > > prospective employers what will happen if someone fakes an email as coming > > from you and sends a trojan or a virus? > > Mmmm... yeah, we'd better put in a filter to limit the MIME encoding and > extensions of resume attachements to DOC, PDF, WPD, TXT & SXW. I believe DOC files can have viruses in them. As long as we allow attachments this will be an issue. I am not saying you should not continue with the exact same plans you have, just that we should consider what we want to do for the long term. > Maybe. I can see adding a couple new categories after the system is launched > and we get feedback from the users. Otherwise, I think the categories > should be rather inflexible; otherwise we risk ending up with 80 categories, > 50% of which have only one job in them. Although I think it's great you are thinking ahead I don't think we will be flooded with postings that categories will be a problem. Of all the problems this project could possibly have I really wish someday too many postings will be one. I just don't think it will happen any time soon. I wish/hope I am wrong on that though. :-) > > So people are going to attach or cut/paste their resumes? > > Sounds cumbersome. > > Well, if you don't like it, you're welcome to ready your PHP skills. After > you draft a spec to deal with the security issues raised by online storage of > resumes .... Go ahead and do the system as you planned. We can then decide what's next after we have something in place. I think you and your team are doing probably the most difficult part. Getting the project off the ground. I don't think we should do anything to slow you down or distract you othen that just give feedback when you request it.
On Thu, 18 Dec 2003, Francisco Reyes wrote: > I believe DOC files can have viruses in them. As long as we allow > attachments this will be an issue. I am not saying you should not > continue with the exact same plans you have, just that we should > consider what we want to do for the long term. Note that right now, on that VM, its not setup, but all incoming and outgoing email on the main mailing list VM *is* virus checked through clamav ... there is no reason why I can't enable that on the VM that jobs is on as well, to help safeguard for this ... > Although I think it's great you are thinking ahead I don't think we will > be flooded with postings that categories will be a problem. Of all the > problems this project could possibly have I really wish someday too many > postings will be one. I just don't think it will happen any time soon. I > wish/hope I am wrong on that though. :-) Falls under: rather have it planned for, then have to try and implement it later ... included from the onset creates no problems, trying to add it in later could be a nightmare ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664